8 ms·

I feel like when you don't use a framework, you actually end up creating your own framework. And while it is of a great engineering challenge to do so, and quit

I feel like when you don't use a framework, you actually end up creating your own framework. And while it is of a great engineering challenge to do so, and quite fun to think the system through, it uses much time out of the main aim of the project and you then have to train others on it, and maintain it. In the meantime relying on an existing framework that fits your needs (and I'm not talking about some obscure ones with only 10 commits by 1 maintainer), you can probably limit the time spent implementing and debugging "basic" stuff that have already been done, integrating components that don't have great connectors yet, ...

brylie 6y ago
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.
- enriquto 6y ago
  > For the most part, the aspects of a framework that go unused typically don't introduce runtime overhead. You cannot seriously believe this.
  - brylie 6y ago
    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.
- setr 6y ago
  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.
  - fermienrico 6y ago
    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.
    - tartoran 6y ago
      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.
    - 6510 6y ago
      > 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.
  - cryptica 6y ago
    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.
movedx 6y ago
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?
- sputr 6y ago
  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.
- have_faith 6y ago
  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.
  - movedx 6y ago
    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.
- mettamage 6y ago
  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
richeyryan 6y ago
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!"
- pcl 6y ago
  > “ 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”.
  - richeyryan 6y ago
    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.
citrin_ru 6y ago
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.
- akvadrako 6y ago
  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.
lloeki 6y ago
> 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.
KronisLV 6y ago
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://youtu.be/4qN3JBGd1g8?t=2371 - https://speakerdeck.com/eoinwoods/secure-by-design-security-design-principles-for-the-working-architect?slide=31 https://speakerdeck.com/eoinwoods/secure-by-design-security-...
bartimus 6y ago
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.

brylie 6y ago

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.

enriquto 6y ago
> For the most part, the aspects of a framework that go unused typically don't introduce runtime overhead. You cannot seriously believe this.
- brylie 6y ago
  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.
setr 6y ago
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.
- fermienrico 6y ago
  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.
  - tartoran 6y ago
    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.
  - 6510 6y ago
    > 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.
- cryptica 6y ago
  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.

movedx 6y ago

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?

sputr 6y ago
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.
have_faith 6y ago
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.
- movedx 6y ago
  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.
mettamage 6y ago
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

richeyryan 6y ago

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!"

pcl 6y ago
> “ 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”.
- richeyryan 6y ago
  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.

citrin_ru 6y ago

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.

akvadrako 6y ago
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.

lloeki 6y ago

> 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.

KronisLV 6y ago

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://youtu.be/4qN3JBGd1g8?t=2371 - https://speakerdeck.com/eoinwoods/secure-by-design-security-design-principles-for-the-working-architect?slide=31 https://speakerdeck.com/eoinwoods/secure-by-design-security-...

bartimus 6y ago

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.