Likewise, rich frameworks like Django, Laravel, and Rails tend to handle needs you didn't anticipate. They build collective experience and familiarity into your project far beyond the capacity of a single organisation.

For the most part, the aspects of a framework that go unused typically don't introduce runtime overhead.

The problem I think is the inversion of control — django owns your code; you’re just a citizen within its confines. You’re typically hooking into the framework’s runtime, and thus everything you do is mediated by the framework — great when you’re doing what the framework wants you to do, and a massive PITA when you stray from the golden path.

Not to mention it bifurcates the library ecosystem — you end up with a react forms library versus an angular forms library versus a vue forms library that are all fundamentally the same yet somehow split, by nature of the framework they hook into.

This argument makes sense. One of the principles I abide by for all my new projects is that I want the dependencies to be more generic (not specific to the current business domain) than their dependents.

The code hierarchy 'tree' is made up of components which are generic at the leaves but as you get closer to the trunk, the logic becomes more fitted to the business domain.

A framework is generic and yet it requires to be used as the trunk (entry point, top level wrapper) of the project so it reduces the flexibility of the code. Sometimes this is desirable (e.g. maybe reducing the flexibility helps to scale), sometimes it doesn't add anything.

I feel the influence of the framework is stronger in the case of libraries like vue, angular, or react. In those cases, your application lives within the shell of those frameworks, and migrating to a different framework means reimplementing almost everything.

Frameworks like Django, Flask, FastAPI and others are different. It depends how you use them, but they're just libraries for the interface layer of your application. Like you say, inversion of control is the key: you want to make the interface depend on your code, and not the other way around. It should be possible to switch between frameworks without having to make changes to your controller/business layer.

Flask might be better than React, but it's still a framework. The ideal framework is just a library, which nobody is arguing against.

Django is for receiving and responding to HTTP requests. If you want to do something that isn't that then I don't know why you would even use Django. In Django you can write views as functions where you receive the request as an input and return the response. What you do inside your function is completely up to you.

On the other side of the fence: Your own shitty framework owns your code, it locks you into this custom frankenstine thing that is a ball of mud that also smells bad. No one wants to look at it, it brings the best developers to their knees and the docs are impossible to relate to. One dude knows how it works and the tech debt is deep.

I'll take a Django project instead, thank you very much.

This is an age old discussion about appropriate abstraction.

You seem like you didn’t really read the article so whatever you say here is not quite relevant. Using a framework is not excluded and they certainly have their place, but it really does depend on the project or the organization the system is developed and run in. There are places where a web framework is entrenched at a core of a business and Im sorry to say it but this is really misguided. Just using a framework doesn’t absolve you of the responsibility of architecting and thinking a solution through.

Spaghetti with mudballs is not shy to take over code that happens tobe written in a framework, it is just a function how much care is given for a codebase. In cases where a frameworks help it does provide some structure that can be used as an organizing unit but it should not be followed dogmatically.

> This is an age old discussion about appropriate abstraction.

It's not finished. I think the last change was that you don't need to worry anymore that something awful might be hiding under the hood. Sitting there, waiting to take your project where no man wants to go.

> For the most part, the aspects of a framework that go unused typically don't introduce runtime overhead.

You cannot seriously believe this.

For example, some Django projects implement only a REST interface. Since those projects don't rely on HTML templates, they don't likely incur any runtime costs from Django's template modules.

In effect, you can choose which parts of the Django project you import. The parts you don't import aren't likely to get in your way. I think this is generally true for modular software.

You definitely don't want to go reinventing the wheel. The problem that I find, especially in the React community is the belief that everything should be done in the framework. How do you make an API call in React? How do you change the page title in React? How do you convert a string to an integer in React? People create libraries that are closely coupled to React when 90% of what they're trying to achieve could be a plain Javascript module. This isn't just React, its most of the frontend Javascript frameworks.

I think the idea here isn't to abandon frameworks entirely but to use them judiciously and appreciate what can live outside the framework as much as what the framework already gives you:

"Nonetheless, we believe that a framework, when chosen, should be used responsibly throughout the life of the project. Continuously remind yourself that every tool has some kind of tradeoff.

Frameworkless means that you must give the right importance to the technological decision making and realize that the choice to develop a project or a single feature with no dependence on a framework is a real possibility!"

> “ Frameworkless means that you must give the right importance to the technological decision making and realize that the choice to develop a project or a single feature with no dependence on a framework is a real possibility!”

The thing is, following normal English rules “frameworkless” means “without frameworks”. It’s good to see that the authors know this, but sad to see that they are so blatantly tapping into confusing terminology right there in their pitch.

I get it that this has been a bit of a trend (“serverless”, anyone?), but the fact that others do it isn’t a great excuse.

Hey, they could even riff on the theme while staying true to the language by going with “Lessframework Movement”.

I agree with you. I clicked the link being ready to object and leave a comment and found that it was much more in line with my opinions than the title would suggest.

Literally the title isn't what the concept says it is. I think there is an element of marketing at play with it. Some of the alternatives seem tentative. Perhaps the Framework Skeptic Movement is better?

Like Scully in the X-Files, which I've been re-watching lately, you don't go in blind wanting to believe things are as they seem but you look for the evidence and if there is no better explanation then yeah maybe it was a man with a regeneration gene that can't be killed. Maybe relying on the framework is the best way forward.

I mean, it's the same idea behind stainless steel - i.e. steel that stains less, rather than being entirely impervious to staining.

Whether most people will catch onto that is still a relevant concern.

> he problem that I find, especially in the React community is the belief that everything should be done in the framework. How do you make an API call in React? How do you change the page title in React? How do you convert a string to an integer in React? People create libraries that are closely coupled to React when 90% of what they're trying to achieve could be a plain Javascript module. This isn't just React, its most of the frontend Javascript frameworks.

This matches my experience as well. It feels kinda wild - lots of other areas have taught to separate concerns as much as possible, meaning React would just be a View layer that renders content but is unrelated to the rest of the application. In reality, everything seems to get stuffed into React, such that React becomes your entire application.

"React would just be a View layer that renders content but is unrelated to the rest of the application"

This is how I treat it. React or more generally the view handles form state and stuff like modal visibility. Things that a user can interact with so to speak.

I have a lib folder that which is the library of my business logic. Concepts related to our domain, analytics, validation, captchas etc. Some of it is shared between client and server, some of it is specific to either.

Then I have my data layer. From my experience a lot of the data handling is interacting nodes (or stores) that can update asynchronously and react to each other. I use Effector (https://effector.dev) to declaratively map all this.

For example when a user submits their details it triggers the recaptcha check which if successsful triggers the saving of a user and the creation of a lead and once we have a lead token we navigate to the next page in the flow.

Handling logic like that in React can really complicate components and the primitives in React aren't really well suited to it. So I found Effector and its been great. The added bonus is it makes the React components responsible for one thing, which is capturing user interaction. They capture events and forward them into Effector. The React code is clean and if I want to drastically change the UI or alter the flow everything is loosely coupled.

Overall I'm quite skeptical of anything that reinforces this all in one approach to things. I appraise the pitched value and figure out how it can be achieved in a more separate way. The answers might not be immediately obvious and it might not be as easy to get started but I feel the overall result has been great so far.

I haven't worked in React (or frontend) in a long time, but your response is similar to how I have/would try to think about those problems. It seemed (when I was paying attention to React) that thinking was less common and most tools pushed you away from it? Which also kind of pushed me away from React as a tool.

React and frontend in general has a new starters problem. Its a lot of people's first interaction with tech. For better or worse I feel a lot of library maintainers and community aim to cater to the beginner.

On one hand it makes things accessible and lets people get their start in the way I could mess around with CSS on MySpace or other people could copy code out of computer magazines.

On the other hand, it leads to what we might call the PHP problem. Lots of low skill, low experience developers influencing what solutions and approaches become conventional.

I've found people in the community that share my general outlook and I follow what they're doing. I also act as my own compass, letting my experience and the lessons I've learned from other ecosystems like Clojure and OCaml guide my approach. I'm at a stage in my career where I'm leading projects and can lay out the full vision. The developers I work with seem to appreciate the value in my approach and the problems I'm solving so its working out for now.

I'm also gently trying to advocate on here and on Reddit and write blog posts to show how this stuff can be done. I don't think it will change the direction of the community but it at least clarifies what I think and why I think it.

"How do I add two integers together with Twisted?"

https://stackoverflow.com/questions/7313761/how-do-i-add-two...

What a bizarre thing - that question is actually a thought experiment (or something) by the author of Twisted!

Nice, I appreciate the example from another ecosystem.

But it’s a problem with bad developers, not a framework.

On the other hand, think of the code those guys could write without a proper “framework”

If the app requires 1% of what framework can, you likely will end-up with micro-framework which is much smaller and simpler.

With maintenance the same - if your app is really small most time will be spend upgrading framework (and adapting app in case of deprecation of an old API or other incompatible changes). And you cannot just stick with an old framework version because there are security fixes (and the bigger framework the more often they happen).

But for medium sized app which is actively developed framework can be quite useful.

I agree. If I write my own framework which only does what the app needs it does a lot less and can easily be refactored if need be. Usually it isn't a framework at all, just some shared functions. I don't like have tons of unused functionality shipping with my app.

Currently experiencing this at my current place of work. Instead of picking a popular React component framework (though the smaller ones would probably be considered libraries), i'm now stuck creating basic stuff, like new components for tabs and whatnot. That's even more fun when you have coworkers that enjoy lengthy discussions about the implementation (which isn't necessarily a bad thing) in combination with clients that want things done ASAP (which is a bad combination).

On the other hand, there are certain other projects which use frameworks like AngularJS which were essentially dropped and are now in the process of dying out - maintaining solutions written with AngularJS isn't fun either and also wastes time sometimes, especially when new components or other libraries can't be integrated with it easily (no pre-existing integrations for modern stuff exist and our own ones need to be written).

Of course, that's just in regards to the front end development - when talking about back end development, i'd err on the side of caution. Working without a pre-existing framework would mean having to write your own security code and that's generarlly regarded as a very bad and dangerous decision based on what i've heard:

- https://youtu.be/4qN3JBGd1g8?t=2371

- https://speakerdeck.com/eoinwoods/secure-by-design-security-...

I really want to use frameworks, but I find the learning curve is often hard to overcome without using the damn thing daily.

Any advice on this front? Is it just a case of using, using, using and eventually it'll all click?

Honestly no. Developer would not be paid as much as they(we) are if these things were neither easy nor time-consuming. And yes, a lot of learning development is the latter.

That's why the idea, still pushed as some collages "if you know one coding language, you know them all" is so stupid. In the real world you're not a "X language" developer. If you want to be really good/charge a lot you have to be "X framework" developer.

It's insane how quickly and well one can code when you really "get" on the mainstream frameworks. The designers really did a fantastic job. But it takes a while to learn.

Learn one framework quite well. I had the fortune in 2014 to be obsessed with making iOS apps and learned Cocoa Touch as a result.

Later when I learned React, I noticed there already were a couple if concepts that I saw before such as lifecycle methods, to the point I could guess what other lifecycle methods React might have.

Once you are on your fourth framework, while only knowing one well, it will feel all the same. At least it does to me.

The questions I ask are:

- what is the preferred way of working with this framework?

- what constitutes fighting against a framework?

- what concepts look a lot (or are identical to) concepts in other frameworks?

If learning is still difficult:

- who wrote a good beginner book?

When I was learning React, I read The Road To React in a few days, then made a small project, then an actual project.

When I really got serious, I had a lot of code already written that I reused as boilerplate/template code and would simply alter it and expand where necessary, learning more advanced concepts on the way.

YMMV

This is good to know, thanks.

I'm looking at Golang based frameworks my self. I love it as a language and try to use it for everything :-)

I find that the surface area of a framework (amount of concepts you need to learn) is roughly comparable to the number of problems it attempts to solve. Most established frameworks started with a few problems to solve and they picked up new problems to solve on their journey. The worst offenders don't stop adding new problems to solve.

Looking for a simpler framework often starts with sacrificing some of the problems you want to solve (or didn't realise were being solved by the frameworks you're considering). Maybe I'll make a website for sorting frameworks based on more personal concerns like "on-ramping complexity" and "amount of learning required to be productive". Obviously subjective but maybe helpful.

I think there would be a demand for this, from individual developers and organisations too.

Happy to be involved in such a project if you want to fire it up.

> I feel like when you don't use a framework, you actually end up creating your own framework.

It's kind of a reusability fallacy: you have needs, and you implement (or glue together off the shelf small independent blocks) that solve those needs. Of course: you a) structure your code and b) a framework implements similar blocks. So of course a) resembles b) because it solves largely similar problems, especially in the www/HTTP world.

But what doing a) solves that b) can't is that b) is a dependency, and often a big one. The bigger, the higher the chance of a systemic impedance mismatch. And sometimes (more often than we think) the impedance mismatch is too much to bear, and even changes over time as the framework updates, causing cascading costs (including people getting up to speed with the new version). It's all the more frustrating when the impedance mismatch is caused by structural decisions (which are not wrong in themselves!) on technical or functional parts of the framework you're -not- using.

More generally, there's a big myth about reusability in software, which seems to work in an ideal theoretical world, but in practice isn't a fit for everything because reality is messy. There's this big placating warning and shaming over NIH and 2SS, but these should not be dogma.

What I found to be consistently true though, is that simple code produces the best results, both in TTM and saving-my-future-ass-some-bloody-time-and-blood-pressure. But simple is also the hardest. Sometimes it's spinning up over a framework because it's a good fit, sometimes it's skipping or dropping the framework because it's too impacting. Both are OK, and sometimes both are even OK at the same time because overall it's a multivariate trade off.

My last vanilla Javascript project ended up with a library of useful functions which could be used independently. My last vanilla PHP project indeed had some sort of glue layer to tie some things together (routing). But it was more about convenience and less about requirement. Most of the code could be used independently nevertheless.