25 ms·

1. Every sufficiently complex framework-free application contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of a framework. 2. I

by a4isms 4y ago

1. Every sufficiently complex framework-free application contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of a framework. 2. If you have a talented team, that half of a framework can be much better than using a one-size-fits-all framework that is popular because it used to be lean and mean with a small surface area, but has grown over time to do everything for everyone, becoming a complex monster. 3. If you have a small team that hires slowly, it's relatively straightforward to bring new devs up to speed on "the way we do things." if you are hiring rapidly and/or have a large team, the more bespoke things you have, the harder it is to maintain them. 4. Over time, everything degrades. In the long run, many framework-free applications either get walled off as "legacy" apps with new work done in separate services, or replaced outright. If it makes you money before that happens, you win. It is not necessary to try to design architecture that will last for centuries. 5. My last and--to me the most significant--observation is this: You want to pay the majority of your attention to the code that has the greatest impact on your desired outcomes. Using libraries and frameworks is like a business outsourcing things that aren't its core competency and also aren't competitive differentiators. Most software shops do not win by having their own framework or by not having a framework, they win by using something bog-standard and saving their attention for the part of their code that "moves the needle." But that's only "most," and your business may be one of the few.

tomcam 4y ago
Agree completely. I’d like to add a couple of things. 6. Frameworks often handle the last 20% of a project that no one wants to do, such as handling compatibility or accessibility issues. 7. There’s a good chance that the framework has already had to deal with edge cases that you would otherwise learn the hard way
- forgotmypw17 4y ago
  My experience is the exact opposite. Frameworks have a very narrow compatibility and accessibility range, and to get the other (often more than) 20% requires extra hackery which has to be bolted onto the framework in ways that were not foreseen by the framework writers.
  - dozgon 4y ago
    One example I can think of was the Play framework. If you wanted to work with Scala 3 and Play 2.7, you couldn't. You needed to stick with Scala 2.13 to be able to use Play 2.7. This was more than a year ago. Now we have Play 2.8. Is it compatible with Scala 3 now? Edit: I am not entirely sure whether it was possible to make Scala 3 and Play 2.7 work. So my statement above might be partially wrong. However, I had other dependencies too, which required me to use Scala 2.13. Consider to downvote this, if you think I made a false statement. I should have looked up the documentation beforehand and not rely on my (past) personal experience/impression at all. Bad mistake!
  - sanitycheck 4y ago
    I've come to believe the difference between framework-lovers and framework-skeptics is that one (larger) group is generally following a well-trodden path and doing only things the framework authors anticipated. Viewing a framework as a common architecture extracted from the experience of writing lots of software, this makes total sense. Most software looks like X, so a framework like X will look like most software. Those who have problems with frameworks are solving problems that are to some extent novel. Maybe only 10% novel, but that's still enough to feel like the framework is a straitjacket - because everything else is a solved problem and that 10% is the hard bit and the framework just makes it even harder. Perhaps some of those people could re-examine their problem and achieve it in a different way using the framework, but others couldn't. But to say "if you're not using a framework you're doing it wrong" perhaps exposes a lack of experience with unusual problems, and "all software ends up containing a custom framework" is confusing frameworks with architecture.
- berkes 4y ago
  Both could be done with libraries. Things that you (can) put away behind abstractions, layers or wrappers. I'm the author and tried to convey clearly the difference between libraries and frameworks. Both allow code-reuse, both allow "standing on shoulders". But one allows you to do so with freedom of movement, independence and domain constraints (libraries) whereas the other locks you in, enforces architectures and designs and requires workarounds when your domain-requirements differ from what the framework dictates.
hsn915 4y ago
> Every sufficiently complex framework-free application contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of a framework. This is simply false. On the other hand, every sufficiently complex framework-dependant application is way too complex for what it does, and would be a lot simpler if it was not using said framework. > My last and--to me the most significant--observation is this: You want to pay the majority of your attention to the code that has the greatest impact on your desired outcomes. One of your greatest desires should be to have strong propietry technology that you control. Otherwise you are not different from anyone, and anyone can duplicate your work in two months by just using the same framework.
- matthewmacleod 4y ago
  No, it's not "simply false". It's something that many of us have repeatedly observed happening and probably done ourselves at some point. There are of course exceptions, but it's not really fair to bluntly dismiss it. One of your greatest desires should be to have strong propietry technology that you control Yes – and you should be investing your time in making that "strong proprietary technology" more effective, and spending as little time as possible doing all the bits that your competitors didn't have to do because they picked an off-the-shelf solution that did most of it to a "good enough" level.
  - hsn915 4y ago
    This notion that frameworks save you time is just ridicluous. Unless the framework is doing something really complicated and difficult (like, say, a 3D game engine such as the Unreal Engine), chances are it's costing you time and effort. What often ends up happening is you have to do a lot of useless work to get around the limitation of the framework you decided to use at the start. Since most people on HN are in the web space, framework often refers to things like "Django" or "Redux". These beats always cost way more than they provide. For a web server, a library like the standard "net/http" in Go is way more useful than a "framework".
    - tbrownaw 4y ago
couchand 4y ago
The author carefully distiguishes precisely what type of framework they mean. The definition includes multiple parts, but the part that really stands out to me is that a framework dictates the overall flow of control. The suggestion in TFA is to ensure that you consume your dependencies in a decoupled fashion, a move toward utilizing libraries rather than following a framework. I've spent lots of development time in highly-constrained environments that often feel more like a framework than a true platform. When given the opportunity, I'm inclined to follow the author's suggestion to keep dependencies decoupled. Even supposedly fundamental dependencies will eventually need to be swapped out, even if just for a v2. But your domain core should be making monotonic progress towards the distillation of your key concepts and relationships.
- ensignavenger 4y ago
  The author uses Django as an example of a framework... but Django doesn't really fit the definition used. Django does not dictate the flow of your code. It provides some libraries and there are common patterns, but Django is more or less just a set of Python modules you can import and use as you want (A bit of configuration is done for you if you follow common layouts, but you don't have to and can manually do the configuration). What dictates program flow is when you use HTTP with Django (What its primary use case is) but that is dictated by the request/response nature of HTTP not by Django. You can use as little or as much of Django as you want. Naturally, the more of it you use, the more it does for you.
  - indymike 4y ago
    All frameworks are collections of libraries and that usually means you can import and use parts of the framework. Django is exactly what the author is saying is hard to maintain. And mostly all things Django start via wsgi, asgi or manage.py. As the lead developer on three Django based commercial saas products, there is a trade off. Spend your time reinventing the same basic things or spend your time building your product. Even the maintenance argument is really a trade off. When you are small, frameworks help by outsourcing a huge amount of labor. When you can afford more developers, you gain control and maintainability by ditching the framework.
_qyyd 4y ago
Do you think that formal specifications might alleviate logical bugs to an extent? Yes, it appears that companies won't budget that at all. Many seem to ship fast, fix later. It is also on the customer, really. Some people expecting software developers to deliver high quality software (with near 100 % code coverage and exceptional performance), but paying them less and less, is not fair. No wonder, some devs are incentivized to skip unit tests or error handling. Because some employer or some customer won't pay for it. This is the status quo that makes me pessimistic. It appears that software development is gluing things together and make it somehow work. This ain't fun for me.
- ativzzz 4y ago
  I shudder to think about what a formal specification of some of the full stack web projects I've developed would look like. They might take longer than the actual coding of it - especially because specifications change mid project as we build things and realize we actually want them different. Note this is a feature, not a bug, of "agile" development - you learn and adjust on the fly
  - ChrisMarshallNY 4y ago
    I tend to make it up as I go along ([0], [1]). It works for me (I just finished up a new SDK, using this technique[2]). However, this would not work for many outfits. It’s just the way that I work. WFM. YMMV. [0] https://littlegreenviper.com/miscellany/forensic-design-documentation/ https://littlegreenviper.com/miscellany/forensic-design-docu... [1] https://littlegreenviper.com/miscellany/evolutionary-design-specification/ https://littlegreenviper.com/miscellany/evolutionary-design-... [2] https://github.com/LittleGreenViper/LGV_MeetingSDK https://github.com/LittleGreenViper/LGV_MeetingSDK
    - ChrisMarshallNY 4y ago
      Hmm… That’s interesting. I seem to have upset people. I’d certainly be interested in knowing why, as my comment directly addresses the parent, and does not coarsen the discourse.
cratermoon 4y ago
> Using libraries and frameworks is like a business outsourcing things that aren't its core competency and also aren't competitive differentiators. Adopting frameworks is a variation on the the Build vs Buy question, even when there's no money involved. Does the framework provide some features that are necessary for the technology but not core to what your business does? It's probably OK to use. A company that adopts a framework for its core business is essentially giving up any competitive edge, because any company that uses that same framework with the at least the same skill as your team will end up being a viable competitor.
wruza 4y ago
I agree with a sibling commenter after reading the article. The main point, as I see it between the lines, is not to refuse to use functionality (app side), but instead how this functionality should be packaged preferably (module side). Nothing prevents the one “in control” to give it up and expose a meaningful degree of it to a user, along with default mode convenience for those who want boxed version. Frameworks actually add to a deplorable side of the software industry. They encapsulate truly great efforts and wisdom into a package which cannot be unwrapped and used partially. They are like smartest CPUs soldered into shitty boards (or simply incompatible with your requirements) without a chance to unsolder the functionality and use it elsewhere. You can’t make your own and you can’t take one off the shelf. Consider this imaginary example: someone figured out all of the nuances of dom events across all browsers ever and made a clear api to it. Library way is to provide (Context, DomEvent) => MyEvent. Framework way is to create a complex rendering idiom in which MyEvent appears naturally and is an implementation detail. In the latter case you buy two for the price of two, and only so. Or, they want to test a new idea/paradigm in some area. Without composable libraries, they are doomed to repeat all the mistakes you pointed out because to compete with already existing solutions they have to go all the way through issues unrelated to the idea itself. All that only to battle test it. For most library makers, the desired outcome is a sum of all parts, not just one.
- tbrownaw 4y ago
  > Frameworks actually add to a deplorable side of the software industry. They encapsulate truly great efforts and wisdom into a package which cannot be unwrapped and used partially. Do you have a concrete non-hypothetical example? Because I don't think I've seen this.
  - mechanical_bear 4y ago
    Exactly. The framework I’m most familiar with, Symfony, specifically is arranged to be antithetical to this statement.
    - sally_glance 4y ago
throwaway0asd 4y ago
> 1. Every sufficiently complex framework-free application contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of a framework. After 25 years of experience writing software I can honestly say I have encountered many people that agree with this, and perhaps all of them (every single one) have not actually experienced writing an application without a framework. This sentiment sounds correct in theory, but it isn't based on any experience from any one of the people making such a claim. The reason why that is comes down to selection bias and cognitive conservatism. Once you become dependent upon a framework everything looks like a framework, even when it isn't. Therefore everything works as expected (like a framework) or it doesn't, which isn't buggy. So really this isn't a question of the software, but of the developer's capability to perceive (or not) that software. This is why I refer to frameworks as an insane asylum as I described here to 27 up votes: https://news.ycombinator.com/item?id=32914694 https://news.ycombinator.com/item?id=32914694
- inopinatus 4y ago
  > perhaps all of them (every single one) have not actually experienced writing an application without a framework I actually have written software without a framework, so by this standard I feel qualified to comment. Not all software has an implied framework within it. Most Unix command-line utilities do not, for example, with only a few exceptions, and discounting the C standard library as something worthy of the label “framework”. Nevertheless even they exist within an overall architecture that starts to look like one, if you squint, and realise the enormous power of piping stdout around. However, many line-of-business applications do develop sufficient complexity, as the owner/operator adds new features to support their expanding operations, that the subsequent edifice either accretes random code into a horrifying fatberg of unmaintainability, or some wiser developer refactors substantial parts of the interface, business logic, persistence, and runtime configuration, effectively creating a framework within that application on which the logic and interface and so forth subsequently hang, and with a pinch of skill and luck, in a fashion that is more readily reasoned about and amended. Whether that informally-specified framework might be considered worthy of extraction into a unit of software for itself is another matter, and largely a case of programmer hubris.
quickthrower2 4y ago
The adhoc framework will also be half known to 5% the current team and barely known outside of happy path use cases to the rest. If you find a bug with the adhoc framework you need to convince a busy person in another team to spend time to unblock you. Or chuck in another hack and move the ticket to done and walk away slowly with stretched out arms.
- throwaway284962 4y ago
  > If you find a bug with the adhoc framework you need to convince a busy person in another team to spend time to unblock you. Which is not so difficult, because that busy person is in the same organisation as you, and therefor working towards the same goal. Fixing that bug is much more difficult if that person is in an outside organisation, serving many other customers on the same code base (with possible conflicting needs), and/or is not actually in any way accountable for it (open source).
  - mightyRodri 4y ago
    > Which is not so difficult, because that busy person is in the same organisation as you Hopefully. But not necessarily. This argument is spinning in circles. In house projects can be abandoned just as oppen-source ones can. For me that was Powermock for example.
  - quickthrower2 4y ago
    > Which is not so difficult, because that busy person is in the same organisation as you, and therefor working towards the same goal. {evil laugh.mp3}… Ideally yes but in reality: all teams have bottlenecks, and nearly all teams have assholes. Is fixing your problem on their OKR or whatever. Free / open source code can be fixed by anyone: the volunteer owner (who you could even bribe to fix it), any contractor with experience, or someone in the org. This is the beauty with free software. It enables people to fix their printer drivers even if they didn’t write it originally.
    - sanitycheck 4y ago
resonious 4y ago
This is good and I pretty much agree. One thing though is that I think #1 and #4 actually also apply to framework'd applications. In my experience, even apps built on Rails end up with a business logic-level "framework" that is ad hoc and not obvious to newcomers, which results in bugs. Not to mention, the frameworks tend to be hard to use "correctly". Rails devs will have heard the term "the Rails way". In fact this article has an awesome example. There's a snippet of code of a controller checking to see if a User exists with the given email. Any Rails veteran would know that you can just call `User.create` in the controller and rely on validations for that kind of check. But that's another problem with frameworks - you have to know the whole thing in order to use it well.
- Daishiman 4y ago
  > But that's another problem with frameworks - you have to know the whole thing in order to use it well. This applies to whatever in-house monstrosities get built too, except that without docs or a million eyeballs to judge whether a workflow makes some sense to an outsider.
  - resonious 4y ago
    Right. I'm definitely not trying to say that apps on a framework are actually larger and nastier than frameworkless apps. They both get large and nasty.
- scarface74 4y ago
  > But that's another problem with frameworks - you have to know the whole thing in order to use it well. The difference is I have plenty of resources at my disposal to learn how to use a popular framework. I only have hopefully the one “architect” who thought their problem was a special snowflake to ask about their framework - if they are still at the company.
- flomo 4y ago
  That has long been one of my complaints about Rails. It creates a nice directory structure for the framework's objects. But there's no obvious place by default to put business/application "your logic". So then all that stuff gets wedged into huge controller and model files. (in the old days there was a division between 'business objects' vs 'data objects' etc) #1 is definitely true. I had my own halfassed 'framework', and have dug into enough older web apps to know that everyone else had one too. (Or at least the smart ones did.)
eyelidlessness 4y ago
> Every sufficiently complex framework-free application contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of a framework. Or three or twelve of them.
- eyelidlessness 4y ago
  I want to credit both the reference (it’s about lisps) and my frame of reference (there are at least a couple of should-be lisps in projects I maintain, and at least one more I think would benefit from a going concern that seldom gets recognized as lispy but absolutely is).
sbf501 4y ago
I think this argument is about free vs. not-free frameworks. Frameworks that are supported by a company and actively developed are far superior to the state of NPM open source right now (thinking of Qt vs Electron and my 7 year battle with both). It is no fun when an open-source framework pushes a new major version, then deprecates the version you were on, or dependencies fail to find matching version, and you beg github developers to fix the bug and your issue sits open for months and is then closed with no warning.
- DrewADesign 4y ago
  I think some of your experiences can be explained by your citing NPM as representative of FOSS. Not that there's anything wrong with the astonishing breadth of functionality available in the NPM ecosystem, but stability isn't its strongest comparative suit. OTOH, Django, which was cited by the author, just doesn't have that kind of volatility in its base features.
  - tbrownaw 4y ago
    > Not that there's anything wrong with the astonishing breadth of functionality available in the NPM ecosystem There are at least two things wrong. One is those things is missing standard functionality (eg, leftpad), and the other is a failure to maintain appropriate hubris (eg, is_even).
    - DrewADesign 4y ago
      I don't think those are criticisms of the repository, are they? They seem like criticisms of modern Javascript.
  - sbf501 4y ago
    True. I should have been more clear because NPM =/= FOSS.
- john61 4y ago
  And it is no fun when the manager of the company developing your proprietary framework decides to tank it because of a change in strategy or the competitor buys the company and stops development. Since you have no source code you are forced to do what the commercial interest of foreigners dictate.
Test0129 4y ago
I've been burned by so many frameworks I am hesitant to use one unless the advantage is abundantly clear. Even something as mundane as an ORM can cause massive problems down the line if you're not careful, or you forgot to anticipate the case you need something more complicated than braindead CRUD. Frameworks force you into a paradigm. Yes, to spin up quicker, get new engineers onboarded quicker, etc a framework will do the job. But it's not a free lunch. In exchange for this you are hopelessly intertwined in the author's idea of what makes something good. You're bound to their bugs, you're bound to the nuance, and most importantly you're developing knowledge of a framework, and not what the framework does. Some major frameworks, for example React, might pass the smell test as "just use it". This is the exception and not the rule mostly guided by the fact that Javascript is the absolute hottest garbage to ever grace our unfortunate field. For some people this exchange is worth it. I'd generally recommend a company use pieces of a framework where they can. But to use a whole framework? Let's put it this way, early in my career I was involved in more old rails projects than I care to admit that were FILLED with kludges because no one could justify actually doing it right and in-housing most of it. I've been involved in projects that were hopeless dependent on the ORM-du-jour that were completely hamstrung because the ORM didn't take full advantage of the query planner, or lacked the necessary constructs for complicated queries, etc. ORMs are the worst, in my opinion, because the only other option is to then _force_ the ORM to do what you would've done originally (defeating it's purpose). General purpose web frameworks are close runners up (and related). Your 5 points are nice sounding, and you probably get a lot of CTOs and engineering directors to agree with you. However, as a man in the trenches I can't say anything but you're fortunate to never have been on something complicated enough that a framework hamstrings you. Rescuing a project from a decision made by some framework-first shortsighted genius is the reason we get paid as much as we do.
- Beltalowda 4y ago
  I mostly agree with this, and also with the parent poster. I've seen framework become a big problem, and I've seen shitty ad-hoc frameworks for "framework-less" applications. I've had fairly good success with what I like to call "framework libraries". That is, all or most of the functionality of a framework, but composed more as a library (or rather, a set of libraries) than a framework, giving you the best of both, mostly. ORMs are often given as an example, but I rarely found them as issue as most I've used have an "escape" to allow you to just use SQL if need be. The bigger problems with frameworks are when you want to compose some application in a way the framework doesn't really like (this can be a problem in Rails, for example). I aggressively push things to libraries whenever I work on something; sometimes they can be made public, sometimes not, but even when private it helps a lot in mentality of people, especially with certain kind of devs.
kodah 4y ago
Some counterpoints and personal experience: > 3. If you have a small team that hires slowly, it's relatively straightforward to bring new devs up to speed on "the way we do things." if you are hiring rapidly and/or have a large team, the more bespoke things you have, the harder it is to maintain them. I disagree that framework or no-framework is the distinguishing characteristic. I do think that the quality of the code base, documentation, and onboarding plays a role in how fast devs get onboarded. Anecdotally, the only framework-based projects I've signed on to ended up incurring more onboarding time because I had to learn the framework, how the framework does things, and then how the team does things in the framework. All of this "how" is a step before "why", of which, every step eventually needs to be repeated over the course of my tenure in order to be successful. > 4. Over time, everything degrades. In the long run, many framework-free applications either get walled off as "legacy" apps with new work done in separate services, or replaced outright. If it makes you money before that happens, you win. It is not necessary to try to design architecture that will last for centuries. I've personally never seen this in any language except Java. Spring might as well be Java at many companies. The bespoke applications stay around, in my experience, because: - They exactly match the business requirement and that requirement doesn't change much - People don't know how to work on them or the product has little funding, probably because of the above reason - The company has hired a team to maintain the product that have not moved I've also seen where companies try to replace something bespoke with something written in a framework where the budget expands multiple years in a row and the project never completes because it's impossible to make the framework do what the bespoke product did completely. > 5. My last and--to me the most significant--observation is this: You want to pay the majority of your attention to the code that has the greatest impact on your desired outcomes. To me, this reads as, "we should spend the majority of the time focusing on our core competencies". I've heard this time and time again in this industry and no matter what way I've heard it explained I've never liked it. Businesses that only stay in their core competency, or narrowly define their competency, often stagnate with time. There's a lot less opportunity for organic business growth with that mindset. They'll also have little expertise to solve problems as they scale, other than through purchasing, because they only have knowledge that serves their core competency. The businesses I've seen become most successful alongside strong technical success were businesses that encouraged employees to innovate and experiment in new ways on a rhythm, allowing that innovation to inspire and percolate when it finds a strong usecase.
8n4vidtmkvmk 4y ago
bug ridden mess maybe, but probably not slow. with 0 overhead, things to be fast by default. frameworks add weight.
- cies 4y ago
  > frameworks add weight. Not really true. Sure they add some, but the alternative (libraries) also add weight. So the question should be: do FWs add more weight than using libs directly. There are some FWs in Rust where the weight is very minimal. That said the FWs are also very minimal.
gernb 4y ago
> 4. Over time, everything degrades. In the long run, many framework-free applications either get walled off as "legacy" apps with new work done in separate services, or replaced outright. If it makes you money before that happens, you win. It is not necessary to try to design architecture that will last for centuries not sure what framework-free has to do with. I'd remove the word "framework-free" and it would still be just as true
goodpoint 4y ago
> 1. Every sufficiently complex framework-free application contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of a framework Yet a nicely designed, simple, custom half-framework is cheaper to maintain than a bloated popular framework.
- throwaway290 4y ago
  Unless your half-framework has equivalently good documentation as a popular framework (which hardly ever happens), this thesis break apart as soon as someone who didn't implement your in-house creation needs to maintain your project and fix your bugs.
  - goodpoint 4y ago
    Wrong.
throwaway284962 4y ago
> 1. Every sufficiently complex framework-free application contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of a framework. Of which you are the creator and expert, and have complete control and insight, and can change it in any way you want any time. It is in 100% alignment with your goals at all time. If you use a framework your organisation becomes incredibly complex, because you are now actually competing against the needs of other companies, your competitors, which are also influencing the framework. Your software is custom made for your organisation, it's not mass producing identical systems on an assembly line, so it doesn't make sense to share a common platform like you do with cars. And even if you did, this platform would be a joint venture, and absolutely not made by a subcontractor, and no way in hell some random unpredictable volunteering hobby organisation.
- jarek83 4y ago
  > Of which you are the creator and expert, and have complete control and insight, and can change it in any way you want any time. It is in 100% alignment with your goals at all time. And then you change a job and you take 80% knowledge with you and your now-past project is in deep trouble.
  - coldtea 4y ago
    If knowledge is on a single person alone, then your ex-company has bigger issues than framework or no framework. Not to mention that the interesting parts of your app should be the domain logic and workarounds and solutions used in it for business issues and historical layers of bussiness logic choices. And that a single person can take with them whether there's a framework or not.
    - RamblingCTO 4y ago
      It will always happen to a degree anyway. The more people are experts because of specifics to this company, the worse. Using a framework also improves hiring.
    - randomsearch 4y ago
coldtea 4y ago
>1. Every sufficiently complex framework-free application contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of a framework Every sufficiently complex built-on-top-of-a-framework application contains an ad hoc, informally-specified, bug-ridden, slow implementation of workarounds to the framework's limitations, the overhead of parts it doesn't need, a nightmarish dependency situation, and as a cherry on top, it ends up based on a previous version, of the framework (as the latter's creators rewrite with different APIs every couple of years for no good reason).
- dmitriid 4y ago
  Why not both? :) Often you end up with an external framework, and an internal framework, and workarounds for both of them.... that are trying to evolve into their own framework
cjfd 4y ago
For a "sufficiently complex application" it is more likely than not that the framework of which half was implemented in an "ad hoc, informally-specified, bug-ridden, slow" way actually is not available anywhere. Instead, very likely, some random framework that sounded like its functionality is somewhere in the direction of what is needed was downloaded and now partially helps and partially hinders development. Probably it hinders more than helps. But this assumes "sufficiently complex application". For a simple application it is more likely that a helpful framework is available.
kybernetyk 4y ago
Re point 1: yes. But it’s your bug ridden half framework and you don’t depend on external developers to make sane decisions. I’ve been using static site generators for my product site and app documentation and every time I set up a new dev machine e (or just update the generator) I’m in dependency hell because some plugins had breaking changes etc. that’s why I switched to my own bug ridden php implementation of the site/docs. At least I don’t get to spend the day googling for change logs, etc when I type ‘make’. /rant over
- ihateolives 4y ago
  PHP is a bit of a special case here. I returned to PHP after 10+ years of hiatus and was surprised how easy it is to get shit done for the web, I had forgotten all about it.
dustedcodes 4y ago
Software is a layer cake and in my opinion from 20 years software development experience I firmly believe that the top 1-2 layers of your business application should not rely on some framework if you want to create a great product, stand out amongst competitors and have a technological advantage in terms of innovation and maintenance. Whatever happens at the top 1-2 layers is what your business cares about the most and what defines your business and you want to have 100% control to fine tune it. I've worked in many companies and on many projects and this made a difference every time.
zelphirkalt 4y ago
I would add though, that if the framework consumes much of the attention of the developers, then it is still a loss. And I would add to the title, that using a overly _hyped_ framework will harm the maintenance. Using some framework, simply because it is new or hyped, that will get teams and companies in trouble.
Fire-Dragon-DoL 4y ago
Something I keep observing that seems to be passed over, coming from a Rails background, is that by using a known framework, the company is also accepting the "population" that comes with it, as well as the known problems. I observed many Rails developers and many apps (purely anecdotal, I wish I could run a real study), but the problems are the usual, the ones on top of my mind right now: - database changes affect directly UI code, so a change in the DB requires changing code in a million places - Rails devs don't know SQL as much as they should (often just don't know it), for a framework that so SQL-centered, it's weird - hidden logic (callbacks) These are very common problems with this framework and are well known to hinder company growth and ability to iterate. Would a home-grown framework be better? I cannot tell, but surely if the list of downsides when choosing a framework was written in the splash page, I would be way more scared. "If you use this framework, your db will 100% be coupled with your frontend" is a terrifying statement. Given that, framework should be evaluated for their downsides too, but there isn't even a list of known issues.
- a4isms 4y ago
  100% worthy observation from my career experience. Choice of a framework both attracts a certain type/subculture, and repels another. Example: You have an old app that uses Backbone+CoffeeScript for the front end. If you stick with that, it will absolutely impact your hiring. But what about switching? If you pick React, that will have one impact. If you pick Ember, that will have a different impact. And so forth…
  - a4isms 4y ago
    Also, speaking very specifically about Rails, every architecture is composed of design choices that make some things easy, and other things hard. The default "Rails Way" has a particular dynamic around REST and CRUD that makes it very easy to "Extrude the implementation into the interface," and, "Extrude the implementation into the API." It's what accelerates building a thing the first time, but later on it can work against you. JM2C about this, but it's what I have observed and have lived through refactoring on multiple occasions...
mbrodersen 4y ago
Not my experience at all. The fewer frameworks I use, the more solid and reliable the software tends to be. And you avoid the yearly “our current framework is crab so let’s try something else” rewrite that everybody else seems to be involved in.

by a4isms 4y ago

tomcam 4y ago

Agree completely. I’d like to add a couple of things. 6. Frameworks often handle the last 20% of a project that no one wants to do, such as handling compatibility or accessibility issues. 7. There’s a good chance that the framework has already had to deal with edge cases that you would otherwise learn the hard way

forgotmypw17 4y ago
My experience is the exact opposite. Frameworks have a very narrow compatibility and accessibility range, and to get the other (often more than) 20% requires extra hackery which has to be bolted onto the framework in ways that were not foreseen by the framework writers.
- dozgon 4y ago
  One example I can think of was the Play framework. If you wanted to work with Scala 3 and Play 2.7, you couldn't. You needed to stick with Scala 2.13 to be able to use Play 2.7. This was more than a year ago. Now we have Play 2.8. Is it compatible with Scala 3 now? Edit: I am not entirely sure whether it was possible to make Scala 3 and Play 2.7 work. So my statement above might be partially wrong. However, I had other dependencies too, which required me to use Scala 2.13. Consider to downvote this, if you think I made a false statement. I should have looked up the documentation beforehand and not rely on my (past) personal experience/impression at all. Bad mistake!
- sanitycheck 4y ago
  I've come to believe the difference between framework-lovers and framework-skeptics is that one (larger) group is generally following a well-trodden path and doing only things the framework authors anticipated. Viewing a framework as a common architecture extracted from the experience of writing lots of software, this makes total sense. Most software looks like X, so a framework like X will look like most software. Those who have problems with frameworks are solving problems that are to some extent novel. Maybe only 10% novel, but that's still enough to feel like the framework is a straitjacket - because everything else is a solved problem and that 10% is the hard bit and the framework just makes it even harder. Perhaps some of those people could re-examine their problem and achieve it in a different way using the framework, but others couldn't. But to say "if you're not using a framework you're doing it wrong" perhaps exposes a lack of experience with unusual problems, and "all software ends up containing a custom framework" is confusing frameworks with architecture.
berkes 4y ago
Both could be done with libraries. Things that you (can) put away behind abstractions, layers or wrappers. I'm the author and tried to convey clearly the difference between libraries and frameworks. Both allow code-reuse, both allow "standing on shoulders". But one allows you to do so with freedom of movement, independence and domain constraints (libraries) whereas the other locks you in, enforces architectures and designs and requires workarounds when your domain-requirements differ from what the framework dictates.

hsn915 4y ago

> Every sufficiently complex framework-free application contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of a framework. This is simply false. On the other hand, every sufficiently complex framework-dependant application is way too complex for what it does, and would be a lot simpler if it was not using said framework. > My last and--to me the most significant--observation is this: You want to pay the majority of your attention to the code that has the greatest impact on your desired outcomes. One of your greatest desires should be to have strong propietry technology that you control. Otherwise you are not different from anyone, and anyone can duplicate your work in two months by just using the same framework.

matthewmacleod 4y ago
No, it's not "simply false". It's something that many of us have repeatedly observed happening and probably done ourselves at some point. There are of course exceptions, but it's not really fair to bluntly dismiss it. One of your greatest desires should be to have strong propietry technology that you control Yes – and you should be investing your time in making that "strong proprietary technology" more effective, and spending as little time as possible doing all the bits that your competitors didn't have to do because they picked an off-the-shelf solution that did most of it to a "good enough" level.
- hsn915 4y ago
  This notion that frameworks save you time is just ridicluous. Unless the framework is doing something really complicated and difficult (like, say, a 3D game engine such as the Unreal Engine), chances are it's costing you time and effort. What often ends up happening is you have to do a lot of useless work to get around the limitation of the framework you decided to use at the start. Since most people on HN are in the web space, framework often refers to things like "Django" or "Redux". These beats always cost way more than they provide. For a web server, a library like the standard "net/http" in Go is way more useful than a "framework".
  - tbrownaw 4y ago

couchand 4y ago

The author carefully distiguishes precisely what type of framework they mean. The definition includes multiple parts, but the part that really stands out to me is that a framework dictates the overall flow of control. The suggestion in TFA is to ensure that you consume your dependencies in a decoupled fashion, a move toward utilizing libraries rather than following a framework. I've spent lots of development time in highly-constrained environments that often feel more like a framework than a true platform. When given the opportunity, I'm inclined to follow the author's suggestion to keep dependencies decoupled. Even supposedly fundamental dependencies will eventually need to be swapped out, even if just for a v2. But your domain core should be making monotonic progress towards the distillation of your key concepts and relationships.

ensignavenger 4y ago
The author uses Django as an example of a framework... but Django doesn't really fit the definition used. Django does not dictate the flow of your code. It provides some libraries and there are common patterns, but Django is more or less just a set of Python modules you can import and use as you want (A bit of configuration is done for you if you follow common layouts, but you don't have to and can manually do the configuration). What dictates program flow is when you use HTTP with Django (What its primary use case is) but that is dictated by the request/response nature of HTTP not by Django. You can use as little or as much of Django as you want. Naturally, the more of it you use, the more it does for you.
- indymike 4y ago
  All frameworks are collections of libraries and that usually means you can import and use parts of the framework. Django is exactly what the author is saying is hard to maintain. And mostly all things Django start via wsgi, asgi or manage.py. As the lead developer on three Django based commercial saas products, there is a trade off. Spend your time reinventing the same basic things or spend your time building your product. Even the maintenance argument is really a trade off. When you are small, frameworks help by outsourcing a huge amount of labor. When you can afford more developers, you gain control and maintainability by ditching the framework.

_qyyd 4y ago

Do you think that formal specifications might alleviate logical bugs to an extent? Yes, it appears that companies won't budget that at all. Many seem to ship fast, fix later. It is also on the customer, really. Some people expecting software developers to deliver high quality software (with near 100 % code coverage and exceptional performance), but paying them less and less, is not fair. No wonder, some devs are incentivized to skip unit tests or error handling. Because some employer or some customer won't pay for it. This is the status quo that makes me pessimistic. It appears that software development is gluing things together and make it somehow work. This ain't fun for me.

ativzzz 4y ago
I shudder to think about what a formal specification of some of the full stack web projects I've developed would look like. They might take longer than the actual coding of it - especially because specifications change mid project as we build things and realize we actually want them different. Note this is a feature, not a bug, of "agile" development - you learn and adjust on the fly
- ChrisMarshallNY 4y ago
  I tend to make it up as I go along ([0], [1]). It works for me (I just finished up a new SDK, using this technique[2]). However, this would not work for many outfits. It’s just the way that I work. WFM. YMMV. [0] https://littlegreenviper.com/miscellany/forensic-design-documentation/ https://littlegreenviper.com/miscellany/forensic-design-docu... [1] https://littlegreenviper.com/miscellany/evolutionary-design-specification/ https://littlegreenviper.com/miscellany/evolutionary-design-... [2] https://github.com/LittleGreenViper/LGV_MeetingSDK https://github.com/LittleGreenViper/LGV_MeetingSDK
  - ChrisMarshallNY 4y ago
    Hmm… That’s interesting. I seem to have upset people. I’d certainly be interested in knowing why, as my comment directly addresses the parent, and does not coarsen the discourse.

cratermoon 4y ago

> Using libraries and frameworks is like a business outsourcing things that aren't its core competency and also aren't competitive differentiators. Adopting frameworks is a variation on the the Build vs Buy question, even when there's no money involved. Does the framework provide some features that are necessary for the technology but not core to what your business does? It's probably OK to use. A company that adopts a framework for its core business is essentially giving up any competitive edge, because any company that uses that same framework with the at least the same skill as your team will end up being a viable competitor.

wruza 4y ago

I agree with a sibling commenter after reading the article. The main point, as I see it between the lines, is not to refuse to use functionality (app side), but instead how this functionality should be packaged preferably (module side). Nothing prevents the one “in control” to give it up and expose a meaningful degree of it to a user, along with default mode convenience for those who want boxed version. Frameworks actually add to a deplorable side of the software industry. They encapsulate truly great efforts and wisdom into a package which cannot be unwrapped and used partially. They are like smartest CPUs soldered into shitty boards (or simply incompatible with your requirements) without a chance to unsolder the functionality and use it elsewhere. You can’t make your own and you can’t take one off the shelf. Consider this imaginary example: someone figured out all of the nuances of dom events across all browsers ever and made a clear api to it. Library way is to provide (Context, DomEvent) => MyEvent. Framework way is to create a complex rendering idiom in which MyEvent appears naturally and is an implementation detail. In the latter case you buy two for the price of two, and only so. Or, they want to test a new idea/paradigm in some area. Without composable libraries, they are doomed to repeat all the mistakes you pointed out because to compete with already existing solutions they have to go all the way through issues unrelated to the idea itself. All that only to battle test it. For most library makers, the desired outcome is a sum of all parts, not just one.

tbrownaw 4y ago
> Frameworks actually add to a deplorable side of the software industry. They encapsulate truly great efforts and wisdom into a package which cannot be unwrapped and used partially. Do you have a concrete non-hypothetical example? Because I don't think I've seen this.
- mechanical_bear 4y ago
  Exactly. The framework I’m most familiar with, Symfony, specifically is arranged to be antithetical to this statement.
  - sally_glance 4y ago

throwaway0asd 4y ago

> 1. Every sufficiently complex framework-free application contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of a framework. After 25 years of experience writing software I can honestly say I have encountered many people that agree with this, and perhaps all of them (every single one) have not actually experienced writing an application without a framework. This sentiment sounds correct in theory, but it isn't based on any experience from any one of the people making such a claim. The reason why that is comes down to selection bias and cognitive conservatism. Once you become dependent upon a framework everything looks like a framework, even when it isn't. Therefore everything works as expected (like a framework) or it doesn't, which isn't buggy. So really this isn't a question of the software, but of the developer's capability to perceive (or not) that software. This is why I refer to frameworks as an insane asylum as I described here to 27 up votes: https://news.ycombinator.com/item?id=32914694 https://news.ycombinator.com/item?id=32914694

inopinatus 4y ago
> perhaps all of them (every single one) have not actually experienced writing an application without a framework I actually have written software without a framework, so by this standard I feel qualified to comment. Not all software has an implied framework within it. Most Unix command-line utilities do not, for example, with only a few exceptions, and discounting the C standard library as something worthy of the label “framework”. Nevertheless even they exist within an overall architecture that starts to look like one, if you squint, and realise the enormous power of piping stdout around. However, many line-of-business applications do develop sufficient complexity, as the owner/operator adds new features to support their expanding operations, that the subsequent edifice either accretes random code into a horrifying fatberg of unmaintainability, or some wiser developer refactors substantial parts of the interface, business logic, persistence, and runtime configuration, effectively creating a framework within that application on which the logic and interface and so forth subsequently hang, and with a pinch of skill and luck, in a fashion that is more readily reasoned about and amended. Whether that informally-specified framework might be considered worthy of extraction into a unit of software for itself is another matter, and largely a case of programmer hubris.

quickthrower2 4y ago

The adhoc framework will also be half known to 5% the current team and barely known outside of happy path use cases to the rest. If you find a bug with the adhoc framework you need to convince a busy person in another team to spend time to unblock you. Or chuck in another hack and move the ticket to done and walk away slowly with stretched out arms.

throwaway284962 4y ago
> If you find a bug with the adhoc framework you need to convince a busy person in another team to spend time to unblock you. Which is not so difficult, because that busy person is in the same organisation as you, and therefor working towards the same goal. Fixing that bug is much more difficult if that person is in an outside organisation, serving many other customers on the same code base (with possible conflicting needs), and/or is not actually in any way accountable for it (open source).
- mightyRodri 4y ago
  > Which is not so difficult, because that busy person is in the same organisation as you Hopefully. But not necessarily. This argument is spinning in circles. In house projects can be abandoned just as oppen-source ones can. For me that was Powermock for example.
- quickthrower2 4y ago
  > Which is not so difficult, because that busy person is in the same organisation as you, and therefor working towards the same goal. {evil laugh.mp3}… Ideally yes but in reality: all teams have bottlenecks, and nearly all teams have assholes. Is fixing your problem on their OKR or whatever. Free / open source code can be fixed by anyone: the volunteer owner (who you could even bribe to fix it), any contractor with experience, or someone in the org. This is the beauty with free software. It enables people to fix their printer drivers even if they didn’t write it originally.
  - sanitycheck 4y ago

resonious 4y ago

This is good and I pretty much agree. One thing though is that I think #1 and #4 actually also apply to framework'd applications. In my experience, even apps built on Rails end up with a business logic-level "framework" that is ad hoc and not obvious to newcomers, which results in bugs. Not to mention, the frameworks tend to be hard to use "correctly". Rails devs will have heard the term "the Rails way". In fact this article has an awesome example. There's a snippet of code of a controller checking to see if a User exists with the given email. Any Rails veteran would know that you can just call `User.create` in the controller and rely on validations for that kind of check. But that's another problem with frameworks - you have to know the whole thing in order to use it well.

Daishiman 4y ago
> But that's another problem with frameworks - you have to know the whole thing in order to use it well. This applies to whatever in-house monstrosities get built too, except that without docs or a million eyeballs to judge whether a workflow makes some sense to an outsider.
- resonious 4y ago
  Right. I'm definitely not trying to say that apps on a framework are actually larger and nastier than frameworkless apps. They both get large and nasty.
scarface74 4y ago
> But that's another problem with frameworks - you have to know the whole thing in order to use it well. The difference is I have plenty of resources at my disposal to learn how to use a popular framework. I only have hopefully the one “architect” who thought their problem was a special snowflake to ask about their framework - if they are still at the company.
flomo 4y ago
That has long been one of my complaints about Rails. It creates a nice directory structure for the framework's objects. But there's no obvious place by default to put business/application "your logic". So then all that stuff gets wedged into huge controller and model files. (in the old days there was a division between 'business objects' vs 'data objects' etc) #1 is definitely true. I had my own halfassed 'framework', and have dug into enough older web apps to know that everyone else had one too. (Or at least the smart ones did.)

eyelidlessness 4y ago

> Every sufficiently complex framework-free application contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of a framework. Or three or twelve of them.

eyelidlessness 4y ago
I want to credit both the reference (it’s about lisps) and my frame of reference (there are at least a couple of should-be lisps in projects I maintain, and at least one more I think would benefit from a going concern that seldom gets recognized as lispy but absolutely is).

sbf501 4y ago

I think this argument is about free vs. not-free frameworks. Frameworks that are supported by a company and actively developed are far superior to the state of NPM open source right now (thinking of Qt vs Electron and my 7 year battle with both). It is no fun when an open-source framework pushes a new major version, then deprecates the version you were on, or dependencies fail to find matching version, and you beg github developers to fix the bug and your issue sits open for months and is then closed with no warning.

DrewADesign 4y ago
I think some of your experiences can be explained by your citing NPM as representative of FOSS. Not that there's anything wrong with the astonishing breadth of functionality available in the NPM ecosystem, but stability isn't its strongest comparative suit. OTOH, Django, which was cited by the author, just doesn't have that kind of volatility in its base features.
- tbrownaw 4y ago
  > Not that there's anything wrong with the astonishing breadth of functionality available in the NPM ecosystem There are at least two things wrong. One is those things is missing standard functionality (eg, leftpad), and the other is a failure to maintain appropriate hubris (eg, is_even).
  - DrewADesign 4y ago
    I don't think those are criticisms of the repository, are they? They seem like criticisms of modern Javascript.
- sbf501 4y ago
  True. I should have been more clear because NPM =/= FOSS.
john61 4y ago
And it is no fun when the manager of the company developing your proprietary framework decides to tank it because of a change in strategy or the competitor buys the company and stops development. Since you have no source code you are forced to do what the commercial interest of foreigners dictate.

Test0129 4y ago

I've been burned by so many frameworks I am hesitant to use one unless the advantage is abundantly clear. Even something as mundane as an ORM can cause massive problems down the line if you're not careful, or you forgot to anticipate the case you need something more complicated than braindead CRUD. Frameworks force you into a paradigm. Yes, to spin up quicker, get new engineers onboarded quicker, etc a framework will do the job. But it's not a free lunch. In exchange for this you are hopelessly intertwined in the author's idea of what makes something good. You're bound to their bugs, you're bound to the nuance, and most importantly you're developing knowledge of a framework, and not what the framework does. Some major frameworks, for example React, might pass the smell test as "just use it". This is the exception and not the rule mostly guided by the fact that Javascript is the absolute hottest garbage to ever grace our unfortunate field. For some people this exchange is worth it. I'd generally recommend a company use pieces of a framework where they can. But to use a whole framework? Let's put it this way, early in my career I was involved in more old rails projects than I care to admit that were FILLED with kludges because no one could justify actually doing it right and in-housing most of it. I've been involved in projects that were hopeless dependent on the ORM-du-jour that were completely hamstrung because the ORM didn't take full advantage of the query planner, or lacked the necessary constructs for complicated queries, etc. ORMs are the worst, in my opinion, because the only other option is to then _force_ the ORM to do what you would've done originally (defeating it's purpose). General purpose web frameworks are close runners up (and related). Your 5 points are nice sounding, and you probably get a lot of CTOs and engineering directors to agree with you. However, as a man in the trenches I can't say anything but you're fortunate to never have been on something complicated enough that a framework hamstrings you. Rescuing a project from a decision made by some framework-first shortsighted genius is the reason we get paid as much as we do.

Beltalowda 4y ago
I mostly agree with this, and also with the parent poster. I've seen framework become a big problem, and I've seen shitty ad-hoc frameworks for "framework-less" applications. I've had fairly good success with what I like to call "framework libraries". That is, all or most of the functionality of a framework, but composed more as a library (or rather, a set of libraries) than a framework, giving you the best of both, mostly. ORMs are often given as an example, but I rarely found them as issue as most I've used have an "escape" to allow you to just use SQL if need be. The bigger problems with frameworks are when you want to compose some application in a way the framework doesn't really like (this can be a problem in Rails, for example). I aggressively push things to libraries whenever I work on something; sometimes they can be made public, sometimes not, but even when private it helps a lot in mentality of people, especially with certain kind of devs.

kodah 4y ago

Some counterpoints and personal experience: > 3. If you have a small team that hires slowly, it's relatively straightforward to bring new devs up to speed on "the way we do things." if you are hiring rapidly and/or have a large team, the more bespoke things you have, the harder it is to maintain them. I disagree that framework or no-framework is the distinguishing characteristic. I do think that the quality of the code base, documentation, and onboarding plays a role in how fast devs get onboarded. Anecdotally, the only framework-based projects I've signed on to ended up incurring more onboarding time because I had to learn the framework, how the framework does things, and then how the team does things in the framework. All of this "how" is a step before "why", of which, every step eventually needs to be repeated over the course of my tenure in order to be successful. > 4. Over time, everything degrades. In the long run, many framework-free applications either get walled off as "legacy" apps with new work done in separate services, or replaced outright. If it makes you money before that happens, you win. It is not necessary to try to design architecture that will last for centuries. I've personally never seen this in any language except Java. Spring might as well be Java at many companies. The bespoke applications stay around, in my experience, because: - They exactly match the business requirement and that requirement doesn't change much - People don't know how to work on them or the product has little funding, probably because of the above reason - The company has hired a team to maintain the product that have not moved I've also seen where companies try to replace something bespoke with something written in a framework where the budget expands multiple years in a row and the project never completes because it's impossible to make the framework do what the bespoke product did completely. > 5. My last and--to me the most significant--observation is this: You want to pay the majority of your attention to the code that has the greatest impact on your desired outcomes. To me, this reads as, "we should spend the majority of the time focusing on our core competencies". I've heard this time and time again in this industry and no matter what way I've heard it explained I've never liked it. Businesses that only stay in their core competency, or narrowly define their competency, often stagnate with time. There's a lot less opportunity for organic business growth with that mindset. They'll also have little expertise to solve problems as they scale, other than through purchasing, because they only have knowledge that serves their core competency. The businesses I've seen become most successful alongside strong technical success were businesses that encouraged employees to innovate and experiment in new ways on a rhythm, allowing that innovation to inspire and percolate when it finds a strong usecase.

8n4vidtmkvmk 4y ago

bug ridden mess maybe, but probably not slow. with 0 overhead, things to be fast by default. frameworks add weight.

cies 4y ago
> frameworks add weight. Not really true. Sure they add some, but the alternative (libraries) also add weight. So the question should be: do FWs add more weight than using libs directly. There are some FWs in Rust where the weight is very minimal. That said the FWs are also very minimal.

gernb 4y ago

> 4. Over time, everything degrades. In the long run, many framework-free applications either get walled off as "legacy" apps with new work done in separate services, or replaced outright. If it makes you money before that happens, you win. It is not necessary to try to design architecture that will last for centuries not sure what framework-free has to do with. I'd remove the word "framework-free" and it would still be just as true

goodpoint 4y ago

> 1. Every sufficiently complex framework-free application contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of a framework Yet a nicely designed, simple, custom half-framework is cheaper to maintain than a bloated popular framework.

throwaway290 4y ago
Unless your half-framework has equivalently good documentation as a popular framework (which hardly ever happens), this thesis break apart as soon as someone who didn't implement your in-house creation needs to maintain your project and fix your bugs.
- goodpoint 4y ago
  Wrong.

throwaway284962 4y ago

> 1. Every sufficiently complex framework-free application contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of a framework. Of which you are the creator and expert, and have complete control and insight, and can change it in any way you want any time. It is in 100% alignment with your goals at all time. If you use a framework your organisation becomes incredibly complex, because you are now actually competing against the needs of other companies, your competitors, which are also influencing the framework. Your software is custom made for your organisation, it's not mass producing identical systems on an assembly line, so it doesn't make sense to share a common platform like you do with cars. And even if you did, this platform would be a joint venture, and absolutely not made by a subcontractor, and no way in hell some random unpredictable volunteering hobby organisation.

jarek83 4y ago
> Of which you are the creator and expert, and have complete control and insight, and can change it in any way you want any time. It is in 100% alignment with your goals at all time. And then you change a job and you take 80% knowledge with you and your now-past project is in deep trouble.
- coldtea 4y ago
  If knowledge is on a single person alone, then your ex-company has bigger issues than framework or no framework. Not to mention that the interesting parts of your app should be the domain logic and workarounds and solutions used in it for business issues and historical layers of bussiness logic choices. And that a single person can take with them whether there's a framework or not.
  - RamblingCTO 4y ago
    It will always happen to a degree anyway. The more people are experts because of specifics to this company, the worse. Using a framework also improves hiring.
  - randomsearch 4y ago

coldtea 4y ago

>1. Every sufficiently complex framework-free application contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of a framework Every sufficiently complex built-on-top-of-a-framework application contains an ad hoc, informally-specified, bug-ridden, slow implementation of workarounds to the framework's limitations, the overhead of parts it doesn't need, a nightmarish dependency situation, and as a cherry on top, it ends up based on a previous version, of the framework (as the latter's creators rewrite with different APIs every couple of years for no good reason).

dmitriid 4y ago
Why not both? :) Often you end up with an external framework, and an internal framework, and workarounds for both of them.... that are trying to evolve into their own framework

cjfd 4y ago

For a "sufficiently complex application" it is more likely than not that the framework of which half was implemented in an "ad hoc, informally-specified, bug-ridden, slow" way actually is not available anywhere. Instead, very likely, some random framework that sounded like its functionality is somewhere in the direction of what is needed was downloaded and now partially helps and partially hinders development. Probably it hinders more than helps. But this assumes "sufficiently complex application". For a simple application it is more likely that a helpful framework is available.

kybernetyk 4y ago

Re point 1: yes. But it’s your bug ridden half framework and you don’t depend on external developers to make sane decisions. I’ve been using static site generators for my product site and app documentation and every time I set up a new dev machine e (or just update the generator) I’m in dependency hell because some plugins had breaking changes etc. that’s why I switched to my own bug ridden php implementation of the site/docs. At least I don’t get to spend the day googling for change logs, etc when I type ‘make’. /rant over

ihateolives 4y ago
PHP is a bit of a special case here. I returned to PHP after 10+ years of hiatus and was surprised how easy it is to get shit done for the web, I had forgotten all about it.

dustedcodes 4y ago

Software is a layer cake and in my opinion from 20 years software development experience I firmly believe that the top 1-2 layers of your business application should not rely on some framework if you want to create a great product, stand out amongst competitors and have a technological advantage in terms of innovation and maintenance. Whatever happens at the top 1-2 layers is what your business cares about the most and what defines your business and you want to have 100% control to fine tune it. I've worked in many companies and on many projects and this made a difference every time.

zelphirkalt 4y ago

I would add though, that if the framework consumes much of the attention of the developers, then it is still a loss. And I would add to the title, that using a overly _hyped_ framework will harm the maintenance. Using some framework, simply because it is new or hyped, that will get teams and companies in trouble.

Fire-Dragon-DoL 4y ago

Something I keep observing that seems to be passed over, coming from a Rails background, is that by using a known framework, the company is also accepting the "population" that comes with it, as well as the known problems. I observed many Rails developers and many apps (purely anecdotal, I wish I could run a real study), but the problems are the usual, the ones on top of my mind right now: - database changes affect directly UI code, so a change in the DB requires changing code in a million places - Rails devs don't know SQL as much as they should (often just don't know it), for a framework that so SQL-centered, it's weird - hidden logic (callbacks) These are very common problems with this framework and are well known to hinder company growth and ability to iterate. Would a home-grown framework be better? I cannot tell, but surely if the list of downsides when choosing a framework was written in the splash page, I would be way more scared. "If you use this framework, your db will 100% be coupled with your frontend" is a terrifying statement. Given that, framework should be evaluated for their downsides too, but there isn't even a list of known issues.

a4isms 4y ago
100% worthy observation from my career experience. Choice of a framework both attracts a certain type/subculture, and repels another. Example: You have an old app that uses Backbone+CoffeeScript for the front end. If you stick with that, it will absolutely impact your hiring. But what about switching? If you pick React, that will have one impact. If you pick Ember, that will have a different impact. And so forth…
- a4isms 4y ago
  Also, speaking very specifically about Rails, every architecture is composed of design choices that make some things easy, and other things hard. The default "Rails Way" has a particular dynamic around REST and CRUD that makes it very easy to "Extrude the implementation into the interface," and, "Extrude the implementation into the API." It's what accelerates building a thing the first time, but later on it can work against you. JM2C about this, but it's what I have observed and have lived through refactoring on multiple occasions...

mbrodersen 4y ago

Not my experience at all. The fewer frameworks I use, the more solid and reliable the software tends to be. And you avoid the yearly “our current framework is crab so let’s try something else” rewrite that everybody else seems to be involved in.