Frameworkless Movement(frameworklessmovement.org)
frameworklessmovement.org
Frameworkless Movement
https://www.frameworklessmovement.org/
86 comments
I would be pretty hesitant to suggest not using a framework at a startup of all places (although really anywhere). They may seem overwhelming, but they are ubiquitous for a reason.
Yeah, da baws would agree and I understand that. But this is something I'm interested in anyway. I really want to "learn it to the bottom".
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, ...
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, ...
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?
Any advice on this front? Is it just a case of using, using, using and eventually it'll all click?
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
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'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.
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.
Happy to be involved in such a project if you want to fire it up.
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.
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.
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.
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.
For the most part, the aspects of a framework that go unused typically don't introduce runtime overhead.
> For the most part, the aspects of a framework that go unused typically don't introduce runtime overhead.
You cannot seriously believe this.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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!"
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”.
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.
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.
Whether most people will catch onto that is still a relevant concern.
"How do I add two integers together with Twisted?"
https://stackoverflow.com/questions/7313761/how-do-i-add-two...
https://stackoverflow.com/questions/7313761/how-do-i-add-two...
Nice, I appreciate the example from another ecosystem.
What a bizarre thing - that question is actually a thought experiment (or something) by the author of Twisted!
> 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.
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.
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.
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.
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”
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.
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.
> 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.
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.
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-...
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 see it as a good exercise to discover why frameworks make sense.
And then you build stuff using a framework.
And then you build stuff using a framework.
Every engineer I've ever talked to or read about going frameworkless says the same thing: we ended up rolling our own. And in most cases, with poor results and quite a bit of hair-pulling.
I like to keep an open-mind about all things engineering, and I agree that some of the complexity of the tooling and frameworks that engineers use daily can be overwhelming; there may be simpler ways to do things, and it's very healthy to question the default of using a framework for everything.
However, such a movement will also be judged stringently based on results. How many relatively large-scale and critical applications will it manage to produce economically, and with developers reporting high levels of happiness?
I like to keep an open-mind about all things engineering, and I agree that some of the complexity of the tooling and frameworks that engineers use daily can be overwhelming; there may be simpler ways to do things, and it's very healthy to question the default of using a framework for everything.
However, such a movement will also be judged stringently based on results. How many relatively large-scale and critical applications will it manage to produce economically, and with developers reporting high levels of happiness?
Personally I would consider any developer that advocates what this "movement" advocates as a developer that should never touch any production code. And this is the reason:
> Every engineer I've ever talked to or read about going frameworkless says the same thing: we ended up rolling our own.
Reading their critiques of frameworks the only thing I could say at every point was "yeah, but not using a framework is even worse".
I think this is nothing more than the "I am very smart" sentiment. Well I'm not smarter than (large, respected) framework designers. Most developers aren't. And it's not just a matter of "learning" but a fact that neither I, nor most other developer will ever be. And why should we be - that's just reinventing the wheel, isn't it? We should focus on our own specific domain challenges.
And yes, it means doing things "the framework way". Because most of the time it IS the better way, even if I can't realize that yet (oh, but I will in a few months).
> Every engineer I've ever talked to or read about going frameworkless says the same thing: we ended up rolling our own.
Reading their critiques of frameworks the only thing I could say at every point was "yeah, but not using a framework is even worse".
I think this is nothing more than the "I am very smart" sentiment. Well I'm not smarter than (large, respected) framework designers. Most developers aren't. And it's not just a matter of "learning" but a fact that neither I, nor most other developer will ever be. And why should we be - that's just reinventing the wheel, isn't it? We should focus on our own specific domain challenges.
And yes, it means doing things "the framework way". Because most of the time it IS the better way, even if I can't realize that yet (oh, but I will in a few months).
[deleted]
Yeah I caught myself almost doing something similar when I wanted to implement some internal tools with a React webapp and a backend server that I was going to write in Go because I wanted to learn Go and it seemed like it would have better performance, yada yada.
Then I came to the (obvious) realisation that the other guys have predominantly experience in JS/TS so it would be kind of irresponsible of me to force anyone else who wants to contribute to this now or in the future to have to do it in a new language, rather than the one that we use in our main project. Ended up going with Typescript and I think it was definitely the right choice. For production code you just gotta go with what A) works. B) the rest of the team is familiar with (or has a reasonable chance of learning enough to read/contribute)
Then I came to the (obvious) realisation that the other guys have predominantly experience in JS/TS so it would be kind of irresponsible of me to force anyone else who wants to contribute to this now or in the future to have to do it in a new language, rather than the one that we use in our main project. Ended up going with Typescript and I think it was definitely the right choice. For production code you just gotta go with what A) works. B) the rest of the team is familiar with (or has a reasonable chance of learning enough to read/contribute)
Irresponsible or good job security practice?
I thought it was obvious that you, except for the most trivial systems, would have to roll some kind of replacement. The advantage of rolling your own would be that it could be a simpler, tighter, framework just for your specific use cases.
Just starting to code without any plan or architectural concerns, of course that will go to shit.
And maybe this points to one of the biggest advantages of frameworks. They force (inexperienced) developers into some kind of structure, where there otherwise would be none.
Just starting to code without any plan or architectural concerns, of course that will go to shit.
And maybe this points to one of the biggest advantages of frameworks. They force (inexperienced) developers into some kind of structure, where there otherwise would be none.
In theory you should deeply know how the frameworks that qualify for your project. You need to know it to make a good decision wether to take it or not.
You need to know it deeply if you use it, because frameworks usually offer relatively leaky abstractions where you need to know implementation details for the best results.
You need to know i if you roll your own code, so you understand which parts you can leave off and how to do the parts that you also need (if you cannot reuse code you should always try to copy the idea of existing code and adapt it to your problem first).
In my opinion using a framework or not should always be an informed decision.
You need to know it deeply if you use it, because frameworks usually offer relatively leaky abstractions where you need to know implementation details for the best results.
You need to know i if you roll your own code, so you understand which parts you can leave off and how to do the parts that you also need (if you cannot reuse code you should always try to copy the idea of existing code and adapt it to your problem first).
In my opinion using a framework or not should always be an informed decision.
Have fun recreating everything a good framework does provide you and see your competitors running away because they will have a much higher developing as they don‘t have to constantly reinvent the wheel.
Every frameworkless project i have seen was total spaghetti code vbecause there were no clear rules. Or they build their custom in-house framework you had to learn first which was highly inferior to open source ones.
How about a databaseless movement? /s
Every frameworkless project i have seen was total spaghetti code vbecause there were no clear rules. Or they build their custom in-house framework you had to learn first which was highly inferior to open source ones.
How about a databaseless movement? /s
You can just substitute "framework" with any abstraction, eg "operating system", "graphics driver", "programming language". Might as well have been called the looking-under-the-hood movement.
Let's ditch the standard libraries too
They are very powerful tools, written in plain vanilla language and in a very generic way, a fact that makes them great learning tools which can help anyone learn how to code without them. In order to know how and when you should use a particular framework you have to understand how frameworks work.
Understanding the strengths and the constraints of each framework will enable you to make the right choice of a framework. Even more, it will be very clear when you don't need one at all. Grasping the concepts of how frameworks work behind the scenes will deepen your knowledge about the language itself. Knowing the framework's rationale will enable you to write better code for each specific problem you encounter.
> But its not gonna be feasible in any environment I've ever worked in, the requirement that everyone should be at the exact same skilled professional mindset and experience.
You don't need the same levels of experience to do this. It's not like junior engineers are the ones picking frameworks to use, that's the responsibility of a manager/TL.
You don't need the same levels of experience to do this. It's not like junior engineers are the ones picking frameworks to use, that's the responsibility of a manager/TL.
The term framework itself is kind of hard to define and in many cases almost identical to "library". Is express.js a library or already framework? Or both? At least it calls itself a framework..
Many libraries or frameworks do one thing and one thing well, but there are also frameworks that are a collection of libraries for different purposes. I feel entrenched when frameworks limit library choice by making it hard to switch out components. From that perspective I prefer libraries over frameworks, but the distinction is kind of hard to make.
Many libraries or frameworks do one thing and one thing well, but there are also frameworks that are a collection of libraries for different purposes. I feel entrenched when frameworks limit library choice by making it hard to switch out components. From that perspective I prefer libraries over frameworks, but the distinction is kind of hard to make.
I think the general rule of thumb (which I don't think the op adheres to): if your code calls it, it's a library, if it calls your code, (as in you are fulfilling some interface) it's a framework.
Most helpful comment of the day goes to...!
...which makes the distinction even harder in node, because it is a callback based language. Nearly everything is based on my code being called.
Sticking with the example of express.js, for me it feels more like a library since I'm still in control of the program flow, even though I need to adhere to certain interfaces.
Sticking with the example of express.js, for me it feels more like a library since I'm still in control of the program flow, even though I need to adhere to certain interfaces.
Why is the distinction harder? Node is a framework.
Yeah. I'd also say if it significantly changes the way you code, it's a framework. So I wouldn't consider jQuery a framework, because you could replace any jQuery call with one or more lines of vanilla javascript.
I would call react or backbone.js or angular etc frameworks, because you would have to completely restructure your codebase in most cases - or, at least, create compatible clones of those libraries.
I would call react or backbone.js or angular etc frameworks, because you would have to completely restructure your codebase in most cases - or, at least, create compatible clones of those libraries.
I think this movement comes approximately 10 years late. Microservices led to the growth of devstacks that has replaced frameworks a lot. I don't know a lot of people who start new projects with big frameworks (maybe Java guys), it's all devstacks around me. In some cases, it's sad because frameworks often have things that have to be reimplemented.
> Microservices led to the growth of devstacks that has replaced frameworks a lot.
You are just replacing one framework with another (Kubernetes).
You are just replacing one framework with another (Kubernetes).
Maybe frameworks are simply operating systems, and Kubernetes is just a distributed extension of Unix. So people should ask a question, is that operating system extension well-designed?
How do microservices replace web frameworks at all? Every microservice I've seen uses some web framework (django, flask, asp .net core, spring boot, etc).
I don't think microservices replace frameworks. Building a microservice is no different from building a monolith. The difference is in how you architect the system, not how you implement the components
Please read the article before complaining…
Key point IMHO:
> They [frameworks] are very powerful tools, written in plain vanilla language and in a very generic way, a fact that makes them great learning tools which can help anyone learn how to code without them. In order to know how and when you should use a particular framework you have to understand how frameworks work. Understanding the strengths and the constraints of each framework will enable you to make the right choice of a framework. Even more, it will be very clear when you don't need one at all. Grasping the concepts of how frameworks work behind the scenes will deepen your knowledge about the language itself. Knowing the framework's rationale will enable you to write better code for each specific problem you encounter.
I very much support this. Know your tools!
Key point IMHO:
> They [frameworks] are very powerful tools, written in plain vanilla language and in a very generic way, a fact that makes them great learning tools which can help anyone learn how to code without them. In order to know how and when you should use a particular framework you have to understand how frameworks work. Understanding the strengths and the constraints of each framework will enable you to make the right choice of a framework. Even more, it will be very clear when you don't need one at all. Grasping the concepts of how frameworks work behind the scenes will deepen your knowledge about the language itself. Knowing the framework's rationale will enable you to write better code for each specific problem you encounter.
I very much support this. Know your tools!
I think the problem is that the site seems a little confused about what it wants. I'd consider:
> [we are] interested in developing applications without frameworks.
... and ...
> nor we will ever create campaigns against frameworks
to be in direct contradiction, yet these are in the very first paragraph.
Reading this page, I'd take it as a rallying cry against useless libraries that could be replaced with a few of lines in your codebase that can be understood and changed and adapted, rather than depending on a generic unchangable external source.
Reading the manifesto itself (following the github link) it sounds like a rallying cry against something else entirely - management-dictated technical decisions.
But maybe the confusion is intentional. People will read into it what they want to see.
> [we are] interested in developing applications without frameworks.
... and ...
> nor we will ever create campaigns against frameworks
to be in direct contradiction, yet these are in the very first paragraph.
Reading this page, I'd take it as a rallying cry against useless libraries that could be replaced with a few of lines in your codebase that can be understood and changed and adapted, rather than depending on a generic unchangable external source.
Reading the manifesto itself (following the github link) it sounds like a rallying cry against something else entirely - management-dictated technical decisions.
But maybe the confusion is intentional. People will read into it what they want to see.
This is like applied Dunning-Kruger
This year I picked up Rails again after a 7 year hiatus ( I didn't have the need ).
I am grateful for all the batteries and their maturity. And if it doesn't scale anymore, I am having other problems.
I am grateful for all the batteries and their maturity. And if it doesn't scale anymore, I am having other problems.
A dependency (and that includes a framework) always comes with a cost. When using only a small part of the dependency, it's often better to roll your own than to use the dependency.
When you are able to use large parts of the dependency, then it's often better to use it than to roll your own.
When you are able to use large parts of the dependency, then it's often better to use it than to roll your own.
This site is very sparse, and frankly mealy-mouthed. It doesn’t give any examples of what “frameworks” it would like us to reconsider.
When I read articles like this (why <insert technology> is “bloat”), I often feel there’s a level of arrogance behind it. Like the writer is just assuming that the readers haven’t considered the pros and cons of the frameworks they’ve chosen.
Since the article gives no examples of its own, let’s tak JS/React as an example. IMO, the upside of using React is absolutely enormous, and far exceeds the risks (especially given React’s excellent level of adoption, good ecosystem, etc). If we didn’t use React, we’d basically end up creating our own, shittier “framework” of informal conventions and abstractions, which would never be anywhere near as efficient/useful.
When I read articles like this (why <insert technology> is “bloat”), I often feel there’s a level of arrogance behind it. Like the writer is just assuming that the readers haven’t considered the pros and cons of the frameworks they’ve chosen.
Since the article gives no examples of its own, let’s tak JS/React as an example. IMO, the upside of using React is absolutely enormous, and far exceeds the risks (especially given React’s excellent level of adoption, good ecosystem, etc). If we didn’t use React, we’d basically end up creating our own, shittier “framework” of informal conventions and abstractions, which would never be anywhere near as efficient/useful.
Good thing then that React is a library and not a framework. :) (only slight sarcasm)
Exactly!
The problem is, when do you consider a library more than a library though? And when do you consider yourself more bound to the "framework" than not?
I'd say given the way that react completely inverts the way you structure the code you write, that's more of a framework packaged in a library. It's not a library you can just move away from (unless you like writing DOM compilers in your spare time, or you plan to move to one of the clones written by people who like writing DOM compilers in their spare time).
Do we consider Ruby on Rails a framework? And if so (because the site makes the distinction...) is it the kind we should only use until we can "code without it"? What about in Java-land, Spring or Struts or Hibernate (or even Swing, though that comes packaged with Java so maybe isn't included in the question) - should these be avoided or embraced? (for reasons other than the horror show that each might be)? And then there's PHP frameworks - too numerous to number, but given the pain of trying to write secure PHP code definitely worth considering - do the security benefits outweigh the risks?
I feel like the summary of the original post is "Know your stack" - and that's a great message - but the page conflates Frameworks (which are generally a good thing to use at least until you reach guru status) with spurious libraries that do next to nothing yet introduce another attack vector.
I'm all for developing apps with fewer dependencies - libraries or frameworks. Totally against developing apps without frameworks.
The problem is, when do you consider a library more than a library though? And when do you consider yourself more bound to the "framework" than not?
I'd say given the way that react completely inverts the way you structure the code you write, that's more of a framework packaged in a library. It's not a library you can just move away from (unless you like writing DOM compilers in your spare time, or you plan to move to one of the clones written by people who like writing DOM compilers in their spare time).
Do we consider Ruby on Rails a framework? And if so (because the site makes the distinction...) is it the kind we should only use until we can "code without it"? What about in Java-land, Spring or Struts or Hibernate (or even Swing, though that comes packaged with Java so maybe isn't included in the question) - should these be avoided or embraced? (for reasons other than the horror show that each might be)? And then there's PHP frameworks - too numerous to number, but given the pain of trying to write secure PHP code definitely worth considering - do the security benefits outweigh the risks?
I feel like the summary of the original post is "Know your stack" - and that's a great message - but the page conflates Frameworks (which are generally a good thing to use at least until you reach guru status) with spurious libraries that do next to nothing yet introduce another attack vector.
I'm all for developing apps with fewer dependencies - libraries or frameworks. Totally against developing apps without frameworks.
Most frameworks aren't, at least not in the literal sense.
By definition a framework is mostly transparent. You can see through it, look at it and think "whoa, I am glad that it is already there" or you can conclude "hmm, I think this part over there will not allow me to do that. I might need a different shape of framework or maybe even build it myself."
Most so-called frameworks hide the complexity and do not explain their architectural choices. In consequence, you end up with suboptimal applications quite regularly. They do this by mixing useful tools instead of providing orthogonal features, for instance a specific language for writing templates tangled together with a MVC base.
By definition a framework is mostly transparent. You can see through it, look at it and think "whoa, I am glad that it is already there" or you can conclude "hmm, I think this part over there will not allow me to do that. I might need a different shape of framework or maybe even build it myself."
Most so-called frameworks hide the complexity and do not explain their architectural choices. In consequence, you end up with suboptimal applications quite regularly. They do this by mixing useful tools instead of providing orthogonal features, for instance a specific language for writing templates tangled together with a MVC base.
That sounds like a cute analogy, but even though the wooden framework of a house is mostly see-through and somewhat modular, it would actually be quite cumbersome and effortful to say "okay, but for this particular wall I'm going to do something entirely different", and if you do, then it might turn out that some of the other things you'd like to have on top of it, say, insulation or drywall, no longer fit very well or no longer do their job as intended. In that sense, the word "framework" in programming actually maps quite nicely to the original meaning of the term.
Let's create more work for ourselves! Reinvent the wheel for every project!
I think every dev should try to build a substantial codebase without any frameworks or libraries. You have to go way way beyond the "Hello, world" concept in whatever you're trying to build, ie if you're building a REST API you have to care about request/response headers, caching, middleware, auth, concurrency, dependency injection, etc. You also have to document all of it to the point that another developer could sit down at a workstation and build something substantial in your custom non-framework.
In my experience (both having done this and watched many devs do it), you find out relatively quickly how much a framework was handling for you, and you find out quickly how much you don't actually want to handle yourself. The fun part about doing it all on your own is you have the supreme knowledge of how everything works - there's no guessing and there's no magic. You wrote it, you know exactly what it does. On the flipside, you're on the hook for building it, even the boring parts. Even the parts you don't really care about but have to implement. Even the stuff you actively dislike.
In my experience (both having done this and watched many devs do it), you find out relatively quickly how much a framework was handling for you, and you find out quickly how much you don't actually want to handle yourself. The fun part about doing it all on your own is you have the supreme knowledge of how everything works - there's no guessing and there's no magic. You wrote it, you know exactly what it does. On the flipside, you're on the hook for building it, even the boring parts. Even the parts you don't really care about but have to implement. Even the stuff you actively dislike.
I think they mainly employ a JavaScript perspective where a frameworks lifetime is measured in minutes.
Sure many classical backend frameworks use a central database technology which limits their scalability, but the mature frameworks with sufficient backing behind them still do the job and save a ton of time. With those you will end up with a maintainable application on the long term. Think of django, heck even JavaEE if done right.
Most of you are not Google ;)
Sure many classical backend frameworks use a central database technology which limits their scalability, but the mature frameworks with sufficient backing behind them still do the job and save a ton of time. With those you will end up with a maintainable application on the long term. Think of django, heck even JavaEE if done right.
Most of you are not Google ;)
I've started using React.js in 2014 and I'm still using it today. That's probably quite a lot of minutes TBH.
Month ago I've started another project - again React + Redux. I don't think React.js will disappear from the scene anytime soon.
Month ago I've started another project - again React + Redux. I don't think React.js will disappear from the scene anytime soon.
They name it frameworks, but they seem to rail against libraries instead. A framework is for application development, gives you a handhold and should solve 80% of non-functional problems like idk, API access, escaping, data(base) management, etc.
But a lot of the resources are of the 'you may not need jquery/underscore' variant, which is a different discussion.
But a lot of the resources are of the 'you may not need jquery/underscore' variant, which is a different discussion.
I've used a few light weight frameworks (e.g. re-dom, which is pretty nice) and recently a kotlin-js framework called fritz2. My observation is that even "heavy" frameworks like react are not all that complicated or particularly big. The reality is that most websites don't actually pull in a lot of external code in any case even if they do include a framework. There are a lot of build time dependencies but not a lot that ends up running in a browser with typical frameworks like react, vue, angular, etc.
So, the difference between using a framework and not using a framework in terms of the amount of code you need to write is not that large. Mostly frameworks are just about getting you to structure your code in a particular way. In react's case most of what it does is getting you to generate html via their templating language and having a thin DOM facade to make DOM updates less of a PITA to manage. That thin DOM facade is very easy to replace with something else. E.g. the re-dom code base is tiny and most of it is just some best practices around using the DOM api. React is a bit more elaborate in what it does but most of that is strictly speaking just nice to have and not really required with modern browsers.
Fritz2 is a Kotlin framework that emulates a lot of good stuff in other frameworks. It uses a Kotlin DSLs instead of templates, Kotlin's co-routines and StateFlows for managing state and handling events. Otherwise, it works more or less directly against the DOM. Seems to work and scale fine.
So, the difference between using a framework and not using a framework in terms of the amount of code you need to write is not that large. Mostly frameworks are just about getting you to structure your code in a particular way. In react's case most of what it does is getting you to generate html via their templating language and having a thin DOM facade to make DOM updates less of a PITA to manage. That thin DOM facade is very easy to replace with something else. E.g. the re-dom code base is tiny and most of it is just some best practices around using the DOM api. React is a bit more elaborate in what it does but most of that is strictly speaking just nice to have and not really required with modern browsers.
Fritz2 is a Kotlin framework that emulates a lot of good stuff in other frameworks. It uses a Kotlin DSLs instead of templates, Kotlin's co-routines and StateFlows for managing state and handling events. Otherwise, it works more or less directly against the DOM. Seems to work and scale fine.
I mostly agreed with this sentiment, but how do you get composable, declarative DOM components without a framework?
When writing a software system, you face engineering tradeoffs, such as, how performant or reliable the system must be, how easy it must be to configure, how well documented it must be, under what conditions it needs to work, and so on. Furthermore, different components might have different requirements.
I think main problem with frameworks is that the engineering tradeoffs involved are not clearly stated. Many frameworks aim to solve all of them, and just let you "configure it as you need", but that is foolish. It's like when a scientific theory tries to explain everything, it cannot provide any prediction, because it cannot generalize at all from the data, as every deviation needs to be explained somehow. In the same way, a "universal framework" is an empty shell that, while it can be configured to do anything you want, the configuration itself becomes the work you would have to do, to tie the specific things you want to do in your system together. However, now you're doing it in framework's DSL and not the same language in which you wrote the specific things. This is a trap that many frameworks seem to fall into.
So if the framework you use is too universal, it doesn't add much value, which has to come from dealing with product-specific problems. Some contrast frameworks with libraries, where it is much harder to fall into this trap. If you add a library to your system, you have a good reason, it has to provide some value to justify itself. But framework is by definition the thing on which everything is supposed to stand on, so it's much easier for a kind of inversion happening and instead of framework supporting your software, it's your program that supports the framework.
I think what frameworkless movement wants is to have every product/system have its own framework, in the sense, the system's purpose determine what will the framework look like. I.e. your system is the one tying everything together (it just calls libraries for things), not some framework "alienated" from the problem you're trying to solve.
I am not sure I entirely agree but I think they have a point. I suspect it is possible to create a framework, but one has to be extremely aware of the interoperability requirements. Creating a framework is like creating an operating system, an environment where application programs run. And it's very good question, then, why use framework, as another layer from the operating system? Why not integrate with the OS itself? What does it bring to the table?
I think main problem with frameworks is that the engineering tradeoffs involved are not clearly stated. Many frameworks aim to solve all of them, and just let you "configure it as you need", but that is foolish. It's like when a scientific theory tries to explain everything, it cannot provide any prediction, because it cannot generalize at all from the data, as every deviation needs to be explained somehow. In the same way, a "universal framework" is an empty shell that, while it can be configured to do anything you want, the configuration itself becomes the work you would have to do, to tie the specific things you want to do in your system together. However, now you're doing it in framework's DSL and not the same language in which you wrote the specific things. This is a trap that many frameworks seem to fall into.
So if the framework you use is too universal, it doesn't add much value, which has to come from dealing with product-specific problems. Some contrast frameworks with libraries, where it is much harder to fall into this trap. If you add a library to your system, you have a good reason, it has to provide some value to justify itself. But framework is by definition the thing on which everything is supposed to stand on, so it's much easier for a kind of inversion happening and instead of framework supporting your software, it's your program that supports the framework.
I think what frameworkless movement wants is to have every product/system have its own framework, in the sense, the system's purpose determine what will the framework look like. I.e. your system is the one tying everything together (it just calls libraries for things), not some framework "alienated" from the problem you're trying to solve.
I am not sure I entirely agree but I think they have a point. I suspect it is possible to create a framework, but one has to be extremely aware of the interoperability requirements. Creating a framework is like creating an operating system, an environment where application programs run. And it's very good question, then, why use framework, as another layer from the operating system? Why not integrate with the OS itself? What does it bring to the table?
I read the article and the GitHub page, looking for specific examples that characterize their objectives. I believe they are on to something, but without specific illustrations, it is too abstract. Context matters in decisions, and I believe they are trying to say: just don't default to using a framework based on what you know (everything is React or Rails or...) but ask yourself "do I really need this for this project based on scope and maintainability?" Everything has a cost to it in a project and over time, and the bigger picture must be considered.
One itch I think it is trying to scratch is that often times frameworks stand in for a gap between what the core language and standard libraries support and what is required by the application. For example, web delivered applications have shifted from the traditional server rendered web interface, to single page applications. Web apps that act like applications have requirements that browsers out of the box don't support: often you need to have tables that can be sorted and shifted for example. There are not "native" javascript/DOM mechanisms for this. So enter third party code to facilitate. Which to choose from? In desktop applications, this facility is handled by the UI layer running on the OS. The JS/DOM doesn't provide it and so if you need it: roll your own, use a third party app, etc. But that has baggage you may not want: dependencies, potential security risks, and maintainability. So I think, at least in the web area, there is a gap in what people need for SPAs, and what the underlying JS/DOM provides.
One itch I think it is trying to scratch is that often times frameworks stand in for a gap between what the core language and standard libraries support and what is required by the application. For example, web delivered applications have shifted from the traditional server rendered web interface, to single page applications. Web apps that act like applications have requirements that browsers out of the box don't support: often you need to have tables that can be sorted and shifted for example. There are not "native" javascript/DOM mechanisms for this. So enter third party code to facilitate. Which to choose from? In desktop applications, this facility is handled by the UI layer running on the OS. The JS/DOM doesn't provide it and so if you need it: roll your own, use a third party app, etc. But that has baggage you may not want: dependencies, potential security risks, and maintainability. So I think, at least in the web area, there is a gap in what people need for SPAs, and what the underlying JS/DOM provides.
One thing I've found over the years (particularly after pivoting away from web dev for awhile and toward ERP and WMS development) is that the data is ultimately what's going to drive everything. Consequently, my philosophy has kinda shifted away from a "let's build an app and bolt some DB onto it with an ORM" and more toward "let's build a DB (schema) and build the app around it". This has some implications:
- An ORM is rarely necessary or even desirable. If I'm using a SQL database, I'm very much inclined to stick with SQL (or maybe a thin ORM if it gives a lot of bang for my buck and stays true to SQL's semantics).
- I only really need or want about 10% of a web framework, and that's primarily routing and templates. Once I'm using SQL directly, it's pretty straightforward to just... query directly for exactly what I want to feed into a template, or feed (sanitized!) input directly into a prepared statement. Consequently, the "controllers" are basically just there for access control and maybe some caching.
- The database ends up being the thing driving business logic. This means actually writing triggers, functions/sprocs, etc. and letting the DB be in control of its data and the manipulation thereof.
- Hell, any SQL DB worth its salt these days can query and generate JSON directly. This means a REST API can exist almost entirely as sprocs, and the "web" part boils down entirely to "receive request, feed into sproc, return output".
The main downside of this (besides needing to be really comfortable with SQL) is that this approach puts more strain on the DB servers. Easy to fix, though: shift resources away from the web servers (ain't like they need it) and toward the DB servers.
- An ORM is rarely necessary or even desirable. If I'm using a SQL database, I'm very much inclined to stick with SQL (or maybe a thin ORM if it gives a lot of bang for my buck and stays true to SQL's semantics).
- I only really need or want about 10% of a web framework, and that's primarily routing and templates. Once I'm using SQL directly, it's pretty straightforward to just... query directly for exactly what I want to feed into a template, or feed (sanitized!) input directly into a prepared statement. Consequently, the "controllers" are basically just there for access control and maybe some caching.
- The database ends up being the thing driving business logic. This means actually writing triggers, functions/sprocs, etc. and letting the DB be in control of its data and the manipulation thereof.
- Hell, any SQL DB worth its salt these days can query and generate JSON directly. This means a REST API can exist almost entirely as sprocs, and the "web" part boils down entirely to "receive request, feed into sproc, return output".
The main downside of this (besides needing to be really comfortable with SQL) is that this approach puts more strain on the DB servers. Easy to fix, though: shift resources away from the web servers (ain't like they need it) and toward the DB servers.
This is also what I do, working in the same business space (MRP for manufacturing) . I think it's a nice approach that let's you focus on the business problems at hand.
Discussed here 10 month ago:
https://news.ycombinator.com/item?id=23357921
https://news.ycombinator.com/item?id=23357921
There was also this—not sure if related:
Frameworkless JavaScript - https://news.ycombinator.com/item?id=7030628 - Jan 2014 (188 comments)
Frameworkless JavaScript - https://news.ycombinator.com/item?id=7030628 - Jan 2014 (188 comments)
As a new developer who does have some input into the tools we will try at the startup workplace, I feel pretty overwhelmed with how.... Much.... There is.
That others are saying more or less "just use the language, dabnabit", is great.
[0] https://github.com/frameworkless-movement/awesome-frameworkl...