▲ 45 points
back
85 comments
Discussed here 10 month ago:
There was also this—not sure if related:
Frameworkless JavaScript - https://news.ycombinator.com/item?id=7030628 - Jan 2014 (188 comments)
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, ...
Likewise, rich frameworks like Django, Laravel, and Rails tend to handle needs you didn't anticipate. They build collective experience and familiarity into your project far beyond the capacity of a single organisation.
For the most part, the aspects of a framework that go unused typically don't introduce runtime overhead.
The problem I think is the inversion of control — django owns your code; you’re just a citizen within its confines. You’re typically hooking into the framework’s runtime, and thus everything you do is mediated by the framework — great when you’re doing what the framework wants you to do, and a massive PITA when you stray from the golden path.
Not to mention it bifurcates the library ecosystem — you end up with a react forms library versus an angular forms library versus a vue forms library that are all fundamentally the same yet somehow split, by nature of the framework they hook into.
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!"
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.
Currently experiencing this at my current place of work. Instead of picking a popular React component framework (though the smaller ones would probably be considered libraries), i'm now stuck creating basic stuff, like new components for tabs and whatnot. That's even more fun when you have coworkers that enjoy lengthy discussions about the implementation (which isn't necessarily a bad thing) in combination with clients that want things done ASAP (which is a bad combination).
On the other hand, there are certain other projects which use frameworks like AngularJS which were essentially dropped and are now in the process of dying out - maintaining solutions written with AngularJS isn't fun either and also wastes time sometimes, especially when new components or other libraries can't be integrated with it easily (no pre-existing integrations for modern stuff exist and our own ones need to be written).
Of course, that's just in regards to the front end development - when talking about back end development, i'd err on the side of caution. Working without a pre-existing framework would mean having to write your own security code and that's generarlly regarded as a very bad and dangerous decision based on what i've heard:
- https://youtu.be/4qN3JBGd1g8?t=2371
- https://speakerdeck.com/eoinwoods/secure-by-design-security-...
I really want to use frameworks, but I find the learning curve is often hard to overcome without using the damn thing daily.
Any advice on this front? Is it just a case of using, using, using and eventually it'll all click?
> I feel like when you don't use a framework, you actually end up creating your own framework.
It's kind of a reusability fallacy: you have needs, and you implement (or glue together off the shelf small independent blocks) that solve those needs. Of course: you a) structure your code and b) a framework implements similar blocks. So of course a) resembles b) because it solves largely similar problems, especially in the www/HTTP world.
But what doing a) solves that b) can't is that b) is a dependency, and often a big one. The bigger, the higher the chance of a systemic impedance mismatch. And sometimes (more often than we think) the impedance mismatch is too much to bear, and even changes over time as the framework updates, causing cascading costs (including people getting up to speed with the new version). It's all the more frustrating when the impedance mismatch is caused by structural decisions (which are not wrong in themselves!) on technical or functional parts of the framework you're -not- using.
More generally, there's a big myth about reusability in software, which seems to work in an ideal theoretical world, but in practice isn't a fit for everything because reality is messy. There's this big placating warning and shaming over NIH and 2SS, but these should not be dogma.
What I found to be consistently true though, is that simple code produces the best results, both in TTM and saving-my-future-ass-some-bloody-time-and-blood-pressure. But simple is also the hardest. Sometimes it's spinning up over a framework because it's a good fit, sometimes it's skipping or dropping the framework because it's too impacting. Both are OK, and sometimes both are even OK at the same time because overall it's a multivariate trade off.
My last vanilla Javascript project ended up with a library of useful functions which could be used independently. My last vanilla PHP project indeed had some sort of glue layer to tie some things together (routing). But it was more about convenience and less about requirement. Most of the code could be used independently nevertheless.
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 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.
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).
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.
Oh my God this is exciting, particularly the resources linked at the bottom [0]
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...
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.
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.
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!
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.
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.
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.
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.
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.
I see it as a good exercise to discover why frameworks make sense.
And then you build stuff using a framework.
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.
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.
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.
Good thing then that React is a library and not a framework. :) (only slight sarcasm)
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.
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.
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.
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).
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).
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.
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.
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 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 ;)
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.
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
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.
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?
Let's ditch the standard libraries too
I mostly agreed with this sentiment, but how do you get composable, declarative DOM components without a framework?
This is like applied Dunning-Kruger
Let's create more work for ourselves! Reinvent the wheel for every project!