TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Using a framework will harm the maintenance of your software

476 pointsby excerionsforteover 2 years ago

109 comments

a4ismsover 2 years ago
1. Every sufficiently complex framework-free application contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of a framework.<p>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.<p>3. If you have a small team that hires slowly, it&#x27;s relatively straightforward to bring new devs up to speed on &quot;the way we do things.&quot; if you are hiring rapidly and&#x2F;or have a large team, the more bespoke things you have, the harder it is to maintain them.<p>4. Over time, everything degrades. In the long run, many framework-free applications either get walled off as &quot;legacy&quot; 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.<p>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.<p>Using libraries and frameworks is like a business outsourcing things that aren&#x27;t its core competency and also aren&#x27;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 &quot;moves the needle.&quot;<p>But that&#x27;s only &quot;most,&quot; and your business may be one of the few.
评论 #33186445 未加载
评论 #33185710 未加载
评论 #33187292 未加载
评论 #33187578 未加载
评论 #33186638 未加载
评论 #33185589 未加载
评论 #33186136 未加载
评论 #33188124 未加载
评论 #33188451 未加载
评论 #33185777 未加载
评论 #33188798 未加载
评论 #33186816 未加载
评论 #33187046 未加载
评论 #33213594 未加载
评论 #33188057 未加载
评论 #33188432 未加载
评论 #33185718 未加载
评论 #33187017 未加载
评论 #33189475 未加载
评论 #33224165 未加载
评论 #33185666 未加载
评论 #33187509 未加载
评论 #33187463 未加载
评论 #33188102 未加载
fullstackchrisover 2 years ago
Every time I see anti framework posts I am forced to frusteratedly chime in. This mentality makes me fume... not all of us work on massive teams where building stuff without a framework is even an option.<p>And even then, whats really a &quot;framework&quot;? You could argue it&#x27;s even the language itself. Android apps used to be written in Java, and now they are pushing Kotlin way harder (and it may even be the default soon). Everyone who wrote those JavaScript apps back in the 1990s without TypeScript, are they still just as maintainable as their TypeScript counterparts? Such a shortsided and ignorant view IMO.<p>I think what bugs me the most is any sort of purist mentality (about anything) in software engineering. WE ARE ENGINEEERS. ENGINEERS USE THE RIGHT TOOL FOR THE RIGHT JOB! It should NEVER be &quot;always use X&quot;, &quot;never use Y&quot;. Both X and Y exist for a reason, so they are both useful for some reason.<p>And again, because I&#x27;m an engineer, I&#x27;ve also built my fair share of apps in just &quot;purist&quot; languages, the classic HTML &#x2F; CSS &#x2F; JavaScript, so I&#x27;m not against the purist approach either. Again, right tool for the right job.
评论 #33190887 未加载
评论 #33198361 未加载
评论 #33189588 未加载
jmathaiover 2 years ago
The post is promoting building applications in a loosely coupled but highly cohesive manner. It mentions using libraries when appropriate and not duplicating code.<p>I agree with this but it requires a lead who&#x27;s good at architecting such a codebase. That person also needs to stay with the company for a long time because they&#x27;re essentially replacing the &quot;framework&quot; with bespoke human logic.<p>I think many, maybe most, companies that try to build loosely coupled and highly cohesive code bases end up failing and it ends up being a mess.<p>Frameworks aren&#x27;t perfect. But know what&#x27;s less perfect? Humans. The really big frameworks try and take the human component out and replace it with codified conventions.
评论 #33185471 未加载
评论 #33187485 未加载
评论 #33187736 未加载
评论 #33185469 未加载
ozimover 2 years ago
I love these technical topics because I can open up popcorn bag and read how people with statistical significance of 1 person experience throw their opinions and claim they have it all figured out.<p>In my 14-15 years of experience in software industry I learned that having framework helps mostly with that - having bunch of &quot;know it alls&quot; rounded up to use the same approach instead of having &quot;I know better discussions&quot;.<p>Where frameworks shine is specifically lowering amount of discussions on technical details that has no relevance to the business but has all kind of opinions from devs.<p>Someone in the thread claims - if he is hired he has to learn framework - well I am hiring people with knowledge on framework we use, he might not have been looking for a job lately. I have not seen we hire c# or c or java dev - there is always framework in requirements. Just see how frontend devs ads look &quot;react dev to hire&quot;&#x2F;&quot;angular dev to hire&quot; no one hires &quot;someone who knows html and css&quot;, yes it is requirement to know these but you also have to know at least one framework.
评论 #33191082 未加载
评论 #33190030 未加载
Joel_Mckayover 2 years ago
&quot;Frameworks are designed to take your project hostage&quot; Wow, that is some enterprise level FUD, and with zero citations to back up that assertion.<p><pre><code> While one could possibly see 3rd party external dependencies pose a variable cost, service risk, or security issue... a standalone&#x2F;maintainable site should not have 25 domains for every lame js widget a designer thought looked cool. </code></pre> Those who do not use a good framework, are simply doomed to rewrite a buggier implementation. <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=wvVPdyYeaQU" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=wvVPdyYeaQU</a>
评论 #33187500 未加载
评论 #33187175 未加载
评论 #33188670 未加载
sz4kertoover 2 years ago
I think using a framework can help with the maintenance of the software.<p>Let me use the one that is usually used as a negative example in hacker circles: Spring.<p>Spring has a steep learning curve. Spring feels like too much magic. Spring makes simple things look complicated and hard to understand. Spring is large.<p>On the other hand: I don&#x27;t care about making extremely simple things more complicated. In the enterprise world &#x2F; large-scale SaaS development, we don&#x27;t do extremely simple things. If we wanted to have a service that adds to two integers and returns the result, then it must have unit testing, integration testing, end-to-end testing lifecycle management, documentation, health checks, clusterability.<p>Why? Because we want to make our own lives easier by having ground rules for services and code, and anyone who starts maintaining, improving or operating a service knows that they can expect the stuff mentioned earlier.<p>So Spring gives us these out of the box. People learn it once, and then whenever they start to work on something new, they get Prometheus metrics, testability, proper logging, etc. right off the bat.<p>I find Spring (and other frameworks) annoying and boring as a hacker, and I find them very useful as a CTO when a large team is working on system and people come and go over years or decades.
评论 #33188521 未加载
flobosgover 2 years ago
This article is about software frameworks, by the way. The capitalization made me think it was about the Framework laptop.
评论 #33187177 未加载
评论 #33186431 未加载
评论 #33185750 未加载
评论 #33187688 未加载
jcelerierover 2 years ago
I absolutely disagree. I use Qt for most of my GUI C++ apps, it is very framework-y and a joy to get things done with.<p>Since last year I&#x27;ve been working on a framework for making media processors (audio, etc): <a href="https:&#x2F;&#x2F;github.com&#x2F;celtera&#x2F;avendish" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;celtera&#x2F;avendish</a><p>Every year I have 2&#x2F;3 internship students. This year I put them on this framework as a baseline, compared to the previous years where the students would have to do things more manually through libraries. They all got at least 5 times as much done as the students of the previous years in the same 3-4 months span of time.
mirzapover 2 years ago
On contrary. Not using frameworks (when you have need for them) actually means you build 60% of framework your self, and then you have to maintain your app and your framework. Which is waste of time and resources. In my experience as freelance developer the worst project I could possibly get is from people who invent their own &quot;frameworks&quot; (they just call it &quot;lib&quot;) because they thought they were smart avoiding frameworks like next.js, laravel or springboot. It is a mess to maintain and to implement anything new on that codebase.<p>Complaining that framework wont support you forever because you were too lazy to maintain the software incrementally, is like complaining why php 1.0 or why windows 98 is not supported anymore. It simply doesn&#x27;t make any sense.<p>My advice was always focus on your product, on your app, use as little dependencies as you can, but do not waste time on things that are solved already. Don&#x27;t write your own framework to avoid using some other more mature and better maintained framework or lib. Sure you do not need library dependency which will tell you is something boolean or not, but if you need to add router to your app, use the lib.
评论 #33307301 未加载
评论 #33190258 未加载
SevenNationover 2 years ago
&gt; Many people will argue that not using a framework means write everything yourself. This is a false dichotomy. We can use libraries and frameworks just fine. ...<p>&gt; But we should give them a clear, and well-isolated place in our project. ...<p>There&#x27;s an excellent, if older, presentation called &quot;Architecture, the Lost Years&quot; that addresses exactly this problem and gives very specific, actionable guidance on how to solve it:<p><a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=WpkDN78P884" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=WpkDN78P884</a><p>But how to pull off this decoupling? The answer is both obvious and surprising. Define a boundary. On one side is the framework. On the other side is your code. Through the boundary, only dumb data structure can pass. JSON works. So do structs. So does XML. The point is that these are behaviorless blobs of data.<p>This buys you a lot. You can run your application completely detached from the network, a database, and other expensive dependencies. So testing becomes much simpler and easier. And of course, you can replace the framework by writing new boundary code.<p>The other big lesson has something to do with why frameworks get added to a project in the first place. When designing a system, the goal should be to defer major decisions for a long as possible. That&#x27;s when the best information is available. Sometimes you can just defer until the point becomes moot, which is a major win.<p>Reaching for a framework before being forced to do so sets up the kind of situation the author is talking about.
评论 #33187336 未加载
评论 #33188194 未加载
stevebmarkover 2 years ago
Rails will harm the maintenance of your software*<p>*Is really the accurate summation of the article. And yes, this is well known. Every article about a company upgrading Rails is &quot;it took us several years and only three people died.&quot; And we know better than to use MVC nowadays.<p>No offense to Rubyists, but in the Ruby ecosystem, I have seen a disturbing lack of absorbing information from other programming ecosystems. This article smells like that to me. If you&#x27;ve only used Ruby and Rails, you might not realize some of the dangers and inherent limitations of the design unless you&#x27;ve worked in other ecosystems.
评论 #33188228 未加载
gonzo41over 2 years ago
It&#x27;s been a whilst since we&#x27;ve had one of these on HN. What a bit of fun. My 2c. There&#x27;s a choice about the work you do. does your work satisfy a business requirement, or does it satisfy your ego.<p>I need a site for work for a 3 year project, CRUD, users, auth, sessions. Django&#x27;s perfect for my team of 1.5. It wouldn&#x27;t be responsible to roll my own, when I can have the bare bones of that site up and ready to go within a day.<p>This is like complaining that X company is locked in because of a chipset, and suggesting they branch out into lithography to ease that burden.<p>Is your core business getting things done, or is it flexing by rolling your own framework.
评论 #33188104 未加载
jarek83over 2 years ago
It seems that there are mostly 2 types of devs: - those that use tools, learn them and master in them, - those that always want to create their own tools, and will usually oppose adopting and learning existing ones.<p>I belong to the first type. I love frameworks because they give publicly available documentation that plenty of people contribute to - so my project will have access to all of it even if I&#x27;m gone. Another reason is that frameworks have opportunity to be battle tested in terms of robustness and in terms of use cases. My stance here is that I love to use wheels instead of creating my own ones. I&#x27;m a project developer and not an academia developer.<p>The second type of devs are what I would avoid hiring to my projects if they wouldn&#x27;t be an academia projects. I need to deliver business goals in a most efficient way. That efficiency has to be on multiple levels. One these levels is to that the code won&#x27;t be depending on one or two my best developers, because there is a high chance they will go at some point. My project would then rely only on what they created and documented, hoping that documentation cover everything. But my project would also slowly deteriorate technically, because most devoted contributors would be gone. Frameworks usually take much longer to become abandoned.<p>I believe first type should work for businesses. The second type - should aim academia.
评论 #33189453 未加载
评论 #33189725 未加载
评论 #33188457 未加载
low_tech_punkover 2 years ago
1. &quot;If you don&#x27;t use a framework, you will end up creating one&quot; -- And that&#x27;s exactly how successful frameworks were born. If everyone uses an existing framework, who is to create better frameworks for the future?<p>2. Framework vs. Library -- Framework calls your code; Library is called by your code. There is clear inversion of control. The article touched on this, but I think it&#x27;s a very important distinction to call out.<p>3. Framework makes me think inheritance. Library makes me think composition.<p>4. Framework is like CPUs. A more powerful CPU is a more powerful CPU, no doubt; but you need more power to bring out the performance. If your company don&#x27;t have the resource to deal with the maintenance, Framework becomes a liability rather than asset. But if you can sustain it, it should still be a net positive.<p>5. In addition to the mixing of domain and non-domain concerns, poor Framework bring incomplete abstraction that expands the surface area for reasoning&#x2F;debugging&#x2F;maintaining. A good framework should provide the perfect abstraction that frees the developer from having to descend the stacks. I consider programming languages as good &quot;frameworks&quot;. So are the layered networking architecture.<p>6. Watch out for self-fulfilling prophecies. e.g. in the web frontend framework space, a framework might claim it helps solve problem X, but it might also be very cause problem X. Accessibility, Routing, State Management... a lot of these can be solved by using the platform. Before you reach out for a framework, be sure to assess platform capabilities and single purpose libraries first.<p>7. Reliance on framework can be caused by lack of knowledge. If you are a manager, give your team the time, money, and endorsement they need to learn things, attend conferences, and provide ample budget for training and technical book purchase. They might pay more dividends than a framework does.
8n4vidtmkvmkover 2 years ago
I&#x27;m experiencing this with Laravel. I&#x27;m stuck on 5.2 while they&#x27;re on v9 now because the author thought it would be a good idea to arbitrarily change some method signatures because he regretted his decisions earlier, while not providing any additional value and I don&#x27;t have the time to hunt all these down and refactor everything, and I feel unmotivated when he&#x27;s made it clear he&#x27;s a bad steward. He refused semver for the longest time, not sure if they&#x27;re using it now but even if so, 4 more major breaks is not encouraging
评论 #33187489 未加载
评论 #33187723 未加载
评论 #33187516 未加载
评论 #33188202 未加载
评论 #33187778 未加载
WantonQuantumover 2 years ago
Before you comment with &quot;So you want us to write everything ourselves?&quot;, make sure you read the paragraph that starts with &quot;Many people will argue that not using a framework means write everything yourself. This is a false dichotomy.&quot;
评论 #33185249 未加载
评论 #33185226 未加载
platzover 2 years ago
He likes to generalize the kinds of problems he has with Rails and Rails-like frameworks to <i>all</i> frameworks. This seems impertinent, since Rails-style frameworks are a particular style&#x2F;flavor of framework, those of which I&#x27;m sure experience the problems he describes, but more generally? I&#x27;m not so sure about that.
评论 #33187861 未加载
p-e-wover 2 years ago
Developers use frameworks because frameworks that are used by many others take care of edge cases that most engineers have no chance of fixing, or even discovering, on their own.<p>Web framework code is typically riddled with comments like <i>&quot;this extra margin is added to the input to work around a bug in Internet Explorer 11 where Tibetan characters are cut off&quot;</i>.<p>Good luck solving such issues without having tens of thousands of eyes and hundreds of hands to help you.
评论 #33190151 未加载
ThePhysicistover 2 years ago
From my own experience, writing something without a framework often seems very elegant to yourself, but the moment you try to onboard other people to your framework-less code it becomes a nightmare. Turns out most folks don&#x27;t want to get familiar with e.g. intrinsics of browser technologies, HTTP request processing or other complex things that you&#x27;ve reimplemented in your code, they just want to deliver working software using frameworks and conventions they know.<p>You can think of frameworks like conventions: If enough people know them, it makes life so much easier for everyone, even though the convention might not always be the best fit. To state an analogy, imagine each municipality would invent their own traffic signs from first principles - because it makes maintenance easier for them - and you were tasked to drive through such a city with large speed, learning the conventions as you go. An absolute nightmare. I think that&#x27;s how most programmers feel about code that brings its own framework-less abstractions and technologies.<p>So while I would&#x27;ve been able to write my own frameworks I&#x27;ve become humble and reasonable enough to just default to something that&#x27;s popular and well-known, because it will make life easier for my colleagues or employees.
lmmover 2 years ago
&gt; Many frameworks aren&#x27;t as extreme as Rails with its public interface of over 1200 methods. But all offer an API, functions, classes, to be used by the user of the framework: it&#x27;s the whole point of the framework to offer this!<p>Some frameworks make the effort to make a clear distinction between which methods you can extend, which you can call, and which are framework-internal. The only one I&#x27;ve seen that really did this properly is Wicket, but it absolutely does work: you can fearlessly upgrade even a major version. (Of course the cost is you sometimes find yourself cursing because the method you wanted to override is final, so instead you have to copy-paste it and accept the maintenance burden belongs to you now - but you&#x27;re doing so explicitly in that case).<p>&gt; The more isolation, the better maintainable. The code that handles e.g. token authentication should not be written by us, but be included in a single, well contained, bounded area. One that encapsulates this and translates it into domain language, preferably. E.g. behind a authentication.is_known_as_admin(request.token) rather than sprinkled throughout our controllers, commandline-interfaces, scripts, or async jobs.<p>This sounds superficially like good advice, but it&#x27;s practically impossible in a language without monads, and often ends up as the &quot;inner-platform effect&quot; - sure, you&#x27;ve put a wrapper around the library, but reimplementing your wrapper to switch out that library is no easier than reimplementing your first library&#x27;s API directly on second library. In my experience you&#x27;re better off YOLOing it most of the time. If you ever do need to remove or replace a dependency, you can do the work then rather than front-loading it, and it&#x27;s actually pretty easy - delete the dependency, fix the compilation errors, and you&#x27;re done.
TillEover 2 years ago
This is like saying game engines can be clunky and get in your way (absolutely true), therefore you should just glue a bunch of libraries together.<p>In practice, that almost never works out well. You want to carefully pick the right tools for the job, but those tools will be enormously helpful when dealing with any kind of complex task, even if you can recite a litany of annoyances.<p>Of course if you <i>don&#x27;t</i> have a complex task at hand, go nuts, find a sleek solution that truly fits your needs.
评论 #33188157 未加载
cghover 2 years ago
From the author’s About page: “I mostly work with Ruby on Rails. A professional, Open Source platform which powers enormous (e.g. Twitter.com) and tiny applications.”
评论 #33185315 未加载
评论 #33185377 未加载
tabtabover 2 years ago
We wouldn&#x27;t need bloated convoluted web &amp; JavaScript frameworks if we had a state-ful GUI markup standard. Then any language that can emit and read XML can use the GUI kit&#x2F;browser&#x2F;component, no binders needed. At least in the domain of custom business and administrative CRUD, the end users really want a web-enabled GUI application, as most work is still done on desktops. (&quot;Desktop first&quot; works better for typical biz than &quot;mobile first&quot;.)<p>Somebody criticized the idea saying that one would end up writing their own wrappers for such a language, but that&#x27;s not a problem: one would customize a sub-interface for their own shop&#x27;s needs and conventions. That&#x27;s not a bad thing. But if we had a decent state-ful GUI markup standard, such wrappers would be <i>lite</i>, more about managing domain patterns &amp; defaults than reinventing a GUI engine and common GUI widgets from <i>scratch</i>.<p>Here&#x27;s a partial list of GUI widgets &amp; idioms that DOM lacks or does half-ass: <a href="https:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;programming&#x2F;comments&#x2F;otixwo&#x2F;comment&#x2F;h6zi86w&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;programming&#x2F;comments&#x2F;otixwo&#x2F;comment...</a>
JodieBenitezover 2 years ago
The article tries to generalize but I think it&#x27;s a bad idea since not all frameworks are equal. Back in 2005 (and to this day), I made websites with Django and it was relatively easy to maintain and upgrade them to follow the framework. I can&#x27;t say the same thing about websites I made using the Zend Framework (now Laminas).<p>The <i>wrong</i> framework will harm the maintenance of your software. The <i>right</i> framework will keep it going for decades.<p>Of course it&#x27;s not always obvious how a framework will evolve over time (let alone the requirements of your website&#x2F;app&#x2F;api), so the safe bet is to stick with the ones that already stood the the test of time.
OJFordover 2 years ago
It matches TFA, but I think &#x27;Framework&#x27; in that capitalisation (incorrectly) implies it&#x27;s about Framework (<a href="https:&#x2F;&#x2F;frame.work" rel="nofollow">https:&#x2F;&#x2F;frame.work</a>) the company.<p>I think quotes - &#x27;framework&#x27; - would be better, both here and in the OP; we can fix one of those.
评论 #33185439 未加载
评论 #33185448 未加载
tracerbulletxover 2 years ago
I&#x27;m glad I started my professional career working on a large Django app, I think learning about its abstractions and organization gave me a really good starting point in building my mental model of all the problems sufficiently complex web applications end up having to solve. Now I often find I prefer, or am in a situation where the companies architecture dictates writing projects and services with much simpler dependency graphs, I&#x27;ve also found the prospect of deploying web applications with python a lot less appealing, but there are many reasons the opinionated all-in frameworks like Django and Rails were and are awesome.
twobitshifterover 2 years ago
Maintainability is how long it takes you to solve a problem. If the reliability of the framework exceeds that of code you could write then we&#x27;re limiting the overall scope that must be maintained to begin with. Now on to what issues look like with frameworks, if you use the framework as designed, the code should follow convention - convention improves maintainability. If your framework can&#x27;t do what&#x27;s asked, it&#x27;s been misapplied and another tool is needed. Using a tool improperly is terrible for maintenance
评论 #33186966 未加载
AugustoCASover 2 years ago
I didn&#x27;t read the whole article, but I agree in principle.<p>My rule of thumb is:<p>* Prefer code vs a library if what I want to do is simple and&#x2F;or if the complexity of the library overshadows whatever benefit I get from using it. * Prefer a library vs a framework if the library provides what I need.<p>A couple of examples when using:<p>* The use of the Spring Framework in the Java world to do DI, web apps and many other things. I think java is the only language where a framework has such a bad influence on developers (maybe Ruby and Rails follows it, after all Spring tried hard to copy Rails ease of use). In this example the framework makes a few things easier, by ading a metric ton of complexity. * The npm left-pad library (debacle).<p>This doesn&#x27;t mean that one shouldn&#x27;t use libraries or frameworks, just that they need to be justified. Development is boring and most developers just see shiny stuff and have to use it in production just to get some entretainment.
Octabrainover 2 years ago
Disclaimer: I&#x27;m a DevOps, not a developer, but enjoy writting software side projects at home where I am free to chose whatever I want and don&#x27;t suffer from real world engineering decisions. So, take my opinion on this with that in mind.<p>Traditionally, I&#x27;ve always used Python with whatever framework (Django, Flask, FastAPI) but always had this feeling that I am learning a framework, not digging into the language which is what I would like. Django, for instance: you end up feeling that a big part of it is magical, which is something that I personally dislike.<p>A few months ago I found Go and fell in love with it&#x27;s pragmatism and its non-written (as far as I am aware) rule of not relying on frameworks but instead on just libraries. I find it great, but again, I don&#x27;t have direct experience in the real world to know the trade offs on multiple levels this can bring.
crossroadsguyover 2 years ago
Number of people here (apparently) confusing frameworks and libraries is kinda surprising.<p>With framework, your app becomes the framework and that framework becomes your app. There’s no abstraction and clear separation like with libs. Oh, maybe you can have abstraction with frameworks, but then why use the framework in the first place.
imoverclockedover 2 years ago
&gt; Companies that have, &quot;A team that defines the standards, processes, practices, frameworks or architectures that other teams must follow,&quot; are amongst the lowest performers. Reversed: companies that lack this, amongst the high performers.<p>(formatting edited)<p>1) I&#x27;d like to see real data behind this claim. (feels very anecdata and I have reversely correlated anecdata)<p>2) Companies that have large codebases or large developer populations and don&#x27;t have any of these things are often headed for disaster.
评论 #33186727 未加载
magicalhippoover 2 years ago
Using a framework will <i>affect</i> the maintenance of your software. So you need to consider that aspect before using it. If it will harm or hinder you, depends entirely on the specifics of both the framework and your project.<p>For example, source code availability is a big factor. Is your project short lived, say a prototype, or do you need it working for 10+ years? If the former, source code availability of the framework might not be an issue, if the latter then you certainly want the framework source.<p>Another point is if you need to track the latest version of the framework for some reason, or can you live with an old version. On Windows for example, you can still use Delphi 7, released in 2002, with its VCL framework to develop applications. Won&#x27;t look pretty but will work.
marcus_holmesover 2 years ago
I&#x27;ve worked on projects that use frameworks, and don&#x27;t.<p>My experience:<p>1. Frameworks do save time at the start of the project. There&#x27;s lots of stuff that comes for free and it does get the project going faster.<p>2. Every project that uses a framework (and survives long enough) ends up fighting that framework. And the more comprehensive the framework, the quicker the project reaches this point and the harder the fight is.<p>3. If the team doesn&#x27;t know the framework well at the start of the project, most of the speed gains at the start are lost, and most of the issues with the framework later are worse.<p>In my experience (almost 30 years now), using libraries instead of frameworks gets most of the benefits and stops most of the pain.
jll29over 2 years ago
Architectural mismatch leads to a clash when one&#x27;s own architectur (or framework, for bigger projects) does not align well with another one that one wishes to use. As a friend of mine used to say &quot;frameworks are like hollywood: you can&#x27;t call us - we&#x27;ll call you&quot;.<p>If you can, supply your functionality as a toolbox instead.<p>In the context of NLP, I addressed some of these issues with using frameworks and toolkits in this 2003 paper <a href="https:&#x2F;&#x2F;dl.acm.org&#x2F;doi&#x2F;10.3115&#x2F;1119226.1119233" rel="nofollow">https:&#x2F;&#x2F;dl.acm.org&#x2F;doi&#x2F;10.3115&#x2F;1119226.1119233</a> .
tobyhinloopenover 2 years ago
Better title: Using Rails will harm the maintenance of your software.<p>Because Rails sucks.<p>A framework like Phoenix (Elixir) is perfectly usable as a plugin.
评论 #33188209 未加载
osigurdsonover 2 years ago
Libraries that you can call from your code are conceptually much simpler than frameworks that call your code. I don&#x27;t think this means that zero frameworks should exist, but frameworks are generally not composable (hard to use many in a single application) while libraries compose trivially.
josephcsibleover 2 years ago
The capital F in &quot;Framework&quot; everywhere made me expect at first that this had something to do with the eponymous brand of laptop.
spionover 2 years ago
I agree that there is a problem here, but I think its a slightly different one.<p>Frameworks and libraries both save you time and require you to invest some time. The main question is whether the savings will be bigger than the investment, and that question can be hard to answer.<p>In most cases we tend to err on the side of framework optimism - we presume a framework or library will always save time (don&#x27;t reinvent the wheel, NIH syndrome, etc). Sometimes when we do this, its because we realize the deep rabbit hole of building something like the framework or library we&#x27;re using. Other times, its because we <i>don&#x27;t</i> know whether the hole is deep or not - we don&#x27;t have the expertise to evaluate.<p>I think the second case is where most of the danger lies. Which is why, paradoxically, its a good idea for a software engineer to reimplement a few pieces of general purpose software in a more specific manner every once in a while and live with them for a longer time.<p>Unfortunately, this is not always possible; often the next best thing is to contribute to an existing open source project and ask (in the kindest way possible) why certain things were implemented in a certain way and&#x2F;or learn from its commit and issue history. Learning doesn&#x27;t mean you have to agree with the authors - in fact often even authors will lament certain design decisions that painted them into a corner or increased complexity unnecessarily.<p>Doing the above will make it easier to evaluate wheather a framework (or library) will save time or drain time. Without it, erring on the side of caution seems like the safer option, which is why we keep recommending it. However, sometimes the drain can be significantly bigger than the savings - if you&#x27;re spending most of your time fighting the framework that&#x27;s a signal that something is wrong and we should have a way of listening to that signal and responding strategically.<p>The downside of frameworks that I think the article is correct about: general-purpose software is really hard to get right. Every author has a specific set of experiences and needs which depend on their specific situation. It may be worth spending some time researching the kind of software built with that framework (or library) to see if there is any obvious bias that would make it not fit your problem domain or your specific context.
评论 #33189177 未加载
ddevaultover 2 years ago
Daniel Stone once pointed out a key difference between libweston and wlroots, two competing approaches for generalizing the work involved in building a Wayland compositor, to explain why wlroots succeeds where libweston does not. He drew the key distinction between a <i>framework</i> and a <i>toolkit</i>. Weston is the former and wlroots is the latter.<p>The difference is that a framework is in control and defers to your code from time to time, whereas with a toolkit, you are in control and defer to the toolkit when necessary. A toolkit-style library can still do most or all of the heavy lifting for you in a single library, but this approach is much more powerful and flexible than a framework approach while retaining most of the benefits.<p>Many people view the framework&#x2F;no-framework debate from the angle that the no-framework side describes a hodgepodge of libraries thrown together to create a crappy half-framework in the downstream code, but that is not necessarily the case. A &quot;one big dependency&quot; approach works with or without the framework design, and a toolkit design offers many advantages that the framework approach cannot.
评论 #33208541 未加载
kohlermover 2 years ago
Not sure I agree with this . A dependency is a dependency and you should always think about whether you want that dependency. Whether it is a framework or not is not really the important point. The important point is how much does this dependency &quot;lock in&quot;. e.g. if inversion of control is a framework &quot;thing&quot;, doesn&#x27;t that in principle minimize the impact of the dependency?
meesterdudeover 2 years ago
To put it simply, this reflects an amateur understanding of frameworks. I know where the author is coming from, because I&#x27;ve been there&#x2F;done that&#x2F;tried that. It sounds nice on paper, but experience has shown that this is a poor way to approach software development.<p>I see this kind of mindset with developers who think <i>only</i> about code, and not about solving problems at scale with other people.
评论 #33187781 未加载
habiburover 2 years ago
That brings up the old debate between framework vs library.<p>My personal conclusion had been don&#x27;t use frameworks, rather use libraries.
评论 #33189542 未加载
评论 #33187601 未加载
didipover 2 years ago
The problem with using a framework is that the upgrade tax is steep.<p>Every major version change is basically an Armageddon.<p>This is one reason why micro service design is popular, you can throw away everything later.
评论 #33189585 未加载
huimangover 2 years ago
Most sufficiently complex codebases that aren’t “framework” based will have a poorly implemented, feature-lacking, bug-ridden version of a framework eventually.<p>If Django doesn’t fit the use case for your thing, don’t use it? Just don’t use flask and then start reimplementing Django.<p>Also, Rails is better Django. It’s not even a close comparison.
评论 #33189609 未加载
评论 #33188081 未加载
fbn79over 2 years ago
More experience I do into programming, more and more I coming to the opinion that Framework is just an alias of &quot;Technical debt&quot;. Please use libs, not framework.
sodapopcanover 2 years ago
While I don&#x27;t necessarily agree with most of this article, it&#x27;s very good. It really just illustrates why so many people get jaded with tech.<p>I believe you can absolutely build your own well-documented framework and be successful, but ultimately some little sh*t is probably going to come in either say, &quot;Why aren&#x27;t we using React? Let&#x27;s rewrite in React!&quot; or &quot;I don&#x27;t like how this is done so I&#x27;m just going to redo it some other way I like in this one place.&quot; From here you have your camp of people who say, &quot;Just don&#x27;t let that happen!&quot; and then your other camp of people who say, &quot;I need to hire people, and nobody wants our custom stuff on their resume so let&#x27;s just use TodaysFlavour.js so we can hire whoever and make the investors happy&quot;. And that&#x27;s, like, two scenarios of many.<p>I guess all I&#x27;m saying is that it&#x27;s really hard to find value from articles like this one when the surface area of the context is pretty much unimaginably wide.<p>I like frameworks and two of my professional anecdotes are: I once worked for a company with an absolutely horrid culture yet their codebase was rails done &quot;the rails way (tm)&quot; and it was great! I got my bearings immediately and pretty much had no questions about where anything was (which was good because I didn&#x27;t want to talk to my coworkers... don&#x27;t worry, I didn&#x27;t stay there long). I also worked at a much better company where one or two people were hell-bent on coming up with their own ideas while everyone else mostly didn&#x27;t care and just wanted to get the work done. This is well-and-good but these people had already decided a previous defined way of doing things was no good so they changed that, and when they leave, I can bet that whoever replaces them will decide that their well-documented way of doing things was no good. I wish people would just follow the framework unless it doesn&#x27;t make sense to (which you only actually know after you&#x27;ve tried to do it the framework&#x27;s way).<p>Well, I&#x27;ve written way too much already for a comment... But I&#x27;ll add that I think the biggest thing this article misses is its points around &quot;speed of development&quot;. Speed of development is always important in the beginning. Once the idea has been proven to work market fit, then the generators this article talks about are no longer important.<p>Anyway ya, Imma shut up now. Overall, good article. I&#x27;m going to read it again tomorrow as I&#x27;m sure I missed a lot.
lasereyes136over 2 years ago
Everything or almost everything stated in the article is true. That said, it doesn&#x27;t matter. All software and software ecosystems are ephemeral and you can&#x27;t know what you might need or want in the future, especially years down the road. All software lives in a constantly changing world so attempts to manage maintenance needs in the future can be a fools errand.<p>Yes, decouple your business logic from your frameworks and libraries as much as possible. Don&#x27;t expect that to make your software more maintainable.<p>Yes, be aware the using a framework or any technology is coupling, but also be aware that you can&#x27;t decouple from everything. Make the best decisions you can with the information you have now and have test automation to check for regressions.
oblibover 2 years ago
I decided not to use a framework. I spent about a month going over the &quot;TodoMVC.com&quot; demos with the intent to choose one but after a few weeks of pondering which one I concluded I didn&#x27;t want to invest in any of them.<p>jQuery and Mustache.js do a lot and are easy to use. CouchDB and PouchDB are too and that gave me user authentication, a powerful server side DB, and offline-first&#x2F;local-first features.<p>I&#x27;ve never regretted those decisions but I had no investment in SQL DBs. Over the years since I&#x27;ve seen other&#x27;s who&#x27;ve did struggle with CouchDB and I get that. I came from using CGI.pm&#x27;s &quot;Save&quot; and &quot;Get&quot; functions and CouchDB&#x2F;PouchDB.js are similar in how you use them, but way better.
评论 #33189833 未加载
评论 #33186533 未加载
deltasevennineover 2 years ago
Kind of a useless argument.<p>Frameworks are designed to predict the future about how they&#x27;re going to be used. They&#x27;re often wrong in that prediction but people try to write frameworks nonetheless.<p>If you&#x27;re not using a public framework then you&#x27;re writing one from scratch. If you&#x27;re writing a framework from scratch then you&#x27;re predicting the future. If you&#x27;re predicting the future you&#x27;ll probably be wrong, and the person who came after you is stuck using your framework.<p>Since most people don&#x27;t greenfield apps, most people will be stuck using someone elses framework.<p>The problem with frameworks is the problem with software. How do we design things such that the design has enough flexibility to perfectly anticipate the future?
epguiover 2 years ago
Am I the only one who thinks this is really hard to read?
评论 #33188918 未加载
throwaway290over 2 years ago
This article seems wrong on every possible level.<p>&gt; This makes sense: if everyone in a company is forced to use, say, Django, for any project, regardless, there will be a lot of projects where Django is a very poor choice.<p>Sorry, if you are forced to use a framework that&#x27;s your beef with the company not the framework.<p>&gt; if the use of framework slows down shipping of new features today, it is causing harm. ... when the use of a framework allows shipping features fast early on, at the cost of slowing down the shipping of new features or changes later on, that is harming maintenance. ... when the framework diverts resources into work that has nothing to do with delivering value to your customers.<p>You just described tests. Any app will become slower to maintain as you need to update the increasing amount of tests. Guess what, framework does the bunch of it letting you focus on testing business logic, and it does so at a cost of imposing a structure.<p>&gt; a last type of harm, is when a framework that was once a good fit for a project, is no longer a good fit.<p>That&#x27;s just reality. I guess coming up with your own structure somehow makes your app immune to having to ever refactor it?<p>IMO the author thought framework is a silver bullet that allows you to not think or care about the architecture at all and now is channeling misplaced disappointment.
twhitmoreover 2 years ago
I&#x27;ve had extensive experience on both sides of the fence -- working on apps within existing frameworks, and also maintaining custom frameworks &amp; libs for apps using those. Unfortunately I find this article of very little value.<p>The author&#x27;s claimed idea of &quot;decoupling from the framework&quot; is generally ineffective &amp; impractical. It leads to extra layers of adapters &amp; SPI with high cost and almost always zero value.<p>These sure add bloat &amp; make the codebase pointlessly difficult to navigate, but are improbably unlikely to ever add value in allowing the framework to actually be changed.<p>Difficulties include mismatched abstractions, endless adapter layers, parameter types for methods also all needing to be abstracted, restricted capabilities, difficulty conveying behaviour&#x2F; dynamism rather than static values, and -- of course -- poor performance.<p>Results are severe choke-points hindering functionality, broken abstractions where stuff actually had to be done, and 90% of the SPI abstractions turning out worthless if you ever did try to migrate to another framework.<p>I&#x27;m an architect. I&#x27;ve seen people&#x27;s non-portable abstractions so many times. The article&#x27;s advice just seems so unlikely to help.<p>Pick a framework that offers long-term maintainability and lets you separate out your domain model &amp; business logic, and just code directly in it.<p>Rather than railing against bad frameworks from limited experience (perhaps in rickety languages too), the author should perhaps spend some time to find a good one. Spring is fine for many purposes. The MVC is coupled at the front, but your domain model need not &amp; should not be. Focus on that, which should be your business value.
fleddrover 2 years ago
It&#x27;s funny, this divide between the old world and new world.<p>The old world has a heavy emphasis on computer science itself, theoretical correctness, long term thinking. It has led to the role of the careful software architect, design patterns, UML, the like.<p>Everything about this old world is a fantasy, as it requires ideal conditions. You&#x27;ll need low delivery pressure and a homogenous set of well-disciplined high-end engineers.<p>That&#x27;s not how software is built these days. You need to ship multiple features per engineer per 2 weeks or so. There&#x27;s no time to do it the right way. Worse, most programmers are bread programmers and couldn&#x27;t even grasp deep computer science, most have never studied it. Even better educated engineers compromise due to time pressure. The role of software architect as it was before, barely exists anymore. It&#x27;s just a senior developer winging it.<p>In this context, if anything, frameworks aren&#x27;t opinionated enough. Many don&#x27;t have &quot;batteries included&quot; leaving unlimited options to screw it up. And the team will screw it up.<p>Maintenance? The software cycle in some domains, especially web and apps, is so fast that we&#x27;ll just start over every 3-5 years anyway.
osigurdsonover 2 years ago
&gt;&gt; A team that defines the standards, processes, practices, frameworks or architectures that other teams must follow..are amongst the lowest performers.<p>It is a matter of degree. If teams responsible for this are legitimately trying to make things better (and not just trying to infallible high priests), it can be helpful. If there are established ways of doing things, it can sometimes alleviate the need to make the same decisions over and over again.
评论 #33187890 未加载
glroyalover 2 years ago
I would add that frameworks:<p>* promote helplessness by abstracting away fundamental but tedious tasks one ought to know how to do,<p>* erode the capacity for innovation by making it difficult to contemplate or impossible to implement solutions outside the framework&#x27;s feature set,<p>* achieve an equilibrium I call &#x27;mutually assured mediocrity&#x27; in which a programmer or organization necessarily vows to remain at the same low level of technology as their competitors.
BiteCode_devover 2 years ago
It&#x27;s not an &quot;or&quot; proposition.<p>E.G: a complex django project will have parts that don&#x27;t use the framework at all. In fact, I never ever use forms with Django, and I do use raw SQL.<p>Not to mention you can start with a framework, and remove pieces you don&#x27;t need on the way. Like Instagram did with the django ORM.<p>Of course, you have to choose a framework with the proper balance for this to work.<p>Purists want their project to be homogeneous, but it never ends up that way because engineering is a about compromises and dev is only partially about code.<p>And in the end, you framework will not harms more your maintenance that home made structure, it will just put the burden of maintenance on different levels, which may or may not be what you want depending of your objectives.<p>But usually, you are not Google, and you have neither the requirements or abilities of such a big structures. Which means a framework is likely bringing more than it&#x27;s going to cost you if you look at the project average cost during it&#x27;s entire life. Provided the framework is well made, chosen and integrated, which is a big if, but then you have similar ifs for custom systems.
talkingtabover 2 years ago
Complexity. Specifically the complexity of the framework vs the complexity of your need.<p>Often frameworks&#x2F;libraries solve the whole problem. For example Oauth. If you want to provide &quot;login with {Google, Amazon, Apple, Facebook, Instagram, etc}. then you must deal with the differences and oddities of each implementation of the service. And all the different modes of &quot;login with&quot; and then keep up to date with changes.<p>The difference is the same as that between buying a shovel and an excavator. Excavators are fun - at least until you have to fix them - so if you can afford one there is a temptation.<p>Complexity in software is the product killer. The cost of maintaining ten excavator type solutions can kill your product and your productivity, and can require you to create a maintenance department.<p>Libraries and Frameworks are always a temptation and often are useful, but understanding the full cost and all the downsides increasingly makes what seems like an obvious choice not so good.<p>But what if you need only a very basic flow for Github? Do you need that complexity? You may need to expand your solution, so
henningover 2 years ago
This is what happens when you view your application as an abstract Platonic object, immortal and perfect, outside any actual concrete implementation. Making the app serve web requests is part of the problem to be solved. The problem is the problem. Looking up whether a user exists as part of handling a request is completely fine because that&#x27;s the simplest way to make the app do what it needs to do.<p>If you have some stupid &quot;clean architecture&quot; layer bullshit where your own application doesn&#x27;t know how any of the rest of it works and everything is absurdly decoupled via some hexagonal bullshit, you&#x27;re going to get into shitty situations where e.g. you have to call the database repository to do N queries rather than just one because the &quot;clean domain layer&quot; is written that way and the &quot;HTTP message delivery layer&quot; is only an &quot;implementation detail&quot; that has nothing to do with the pure business domain. Then your product will fucking suck fucking shit and you haven&#x27;t actually solved the problem.
rgloverover 2 years ago
Unless the framework you&#x27;re using treats maintainability as a feature [1], not an afterthought.<p>This is really just a long argument against bad framework <i>design</i> (which is fair), not frameworks.<p>[1] <a href="https:&#x2F;&#x2F;github.com&#x2F;cheatcode&#x2F;joystick#what-distinguishes-joystick-from-other-frameworks" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;cheatcode&#x2F;joystick#what-distinguishes-joy...</a>
nottorpover 2 years ago
&gt; In a framework, unlike in libraries or in standard user applications, the overall program&#x27;s flow of control is not dictated by the caller, but by the framework.<p>&gt; In other words, users can extend the framework, but cannot modify its code.<p>He is talking about a specific kind of framework, not about every library under the sun. And for those he may well be right.<p>Back when Unity was new, most games done with it kinda looked the same. I don&#x27;t know if Unity evolved to allow more control&#x2F;customization or people are just better at working around it now.<p>And if you browse the web, you eventually run into a bunch of sites that all kinda look the same and act the same. Again, this is due to the framework imposing their way to do things instead of the developers&#x2F;designers deciding it. I suppose an experienced web dev could actually recognize what framework a site like that is done on without looking at the source code, just based on behaviour.<p>This may be good for cheap one offs but not so much long term indeed.
forgotmypw17over 2 years ago
Have to agree.<p>Just the framework itself usually requires maintenance, unless the developer prioritizes backwards compatibility, which is rarely the case.
langsoul-comover 2 years ago
Even though he has a point about harming future maintenance and how the framework has no obligation to give a damn about what you need.<p>Ie, see React 18 introducing double rendering for state and useEffect on strict mode (on by default in Nextjs). Makes debugging harder when shit runs twice, all for some future update.
lucasfcostaover 2 years ago
I don’t fully agree. The author has quite a few excellent points, but when one says it may “harm” the “maintenance” of your software one must define which variables are used to measure “maintainability”. Is it MTTR, cycle times, bug density, or what?<p>Speaking of maintenance in broad terms makes the argument fuzzy.
mejutocoover 2 years ago
I heard an analogy between writing without a framework &#x2F; your own framework an nuclear energy that I found fitting (not taking sides either way). Please bear with me.<p>The best-case scenario is better. More energy in the case of nuclear and just what you need, more performant, less code in the case of no framework. Everything just for your use case and no more.<p>But the worse-case is much much worse too. If you drop checks and discipline once (key developer switching jobs without in-team knowledge, for instance) there is no way back and the consequences can be catastrophic.<p>I would conclude than in general it is not worth it, but if you have the discipline and political incentives and&#x2F;or special requirements (big ifs) it can be worth it, as long as those ifs keep being true.<p>I guess my insight is: it depends :)
ontologiaeover 2 years ago
I think most of the problems come from insufficient semantic power of actual language. Most programming language, even the most advanced don&#x27;t manage time, don&#x27;t manage locality, and don&#x27;t fit in the brain representation human makes of the code. It&#x27;s remarkably explained by Blackwell in his paper &quot;Metaphors we Program By: Space, Action and Society in Java&quot; <a href="https:&#x2F;&#x2F;www.ppig.org&#x2F;papers&#x2F;2006-ppig-18th-blackwell&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.ppig.org&#x2F;papers&#x2F;2006-ppig-18th-blackwell&#x2F;</a><p>So frameworks try to manage this gap, and the only solution, IMO, is to invent language that integrate more advanced semantics to avoid the necessity of frameworks
tootieover 2 years ago
&quot;In other words: enforced standardising the tech, doesn&#x27;t pay off.&quot;<p>That&#x27;s a completely different thesis from frameworks are bad. My org uses frameworks extensively and we reevaluate which are fit to purpose at every new project. Rigid enforcement of rules without thoughtful analysis is just a straw man and I&#x27;ve never seen an org that does that.<p>I&#x27;d also just disagree with the rest of the argument. Frameworks provide both speed to market and shared vernacular that makes it easier to onboard team members and find support communities online. I have a small team and some software that is 10+ years old. The maintenance team has turned over 300% since inception. Without a framework we&#x27;d be completely lost.
culiover 2 years ago
As everyone else pointed out, frameworks are a natural evolution of sufficiently complex applications and &quot;framework-less&quot; codebases often have their own proto-framework solutions to things.<p>I don&#x27;t think the issue is frameworks but rather being locked in to a framework. I&#x27;m really interested in seeing where the micro-frontend trend as well as island-centric tools like Astro, Fresh, or Hotwire evolve. Tools like these show it might not be the frameworks themselves but rather the way we use the frameworks that are the issue. Despite React praise for being &quot;a library not a framework&quot;, there is a very clear focus on SPAs throughout the ecosystem and I feel like its potential flexibility is really stifled by this
cnoklebergover 2 years ago
I wrote an article for the ACM which covers how Google uses frameworks: <a href="https:&#x2F;&#x2F;queue.acm.org&#x2F;detail.cfm?id=3447806" rel="nofollow">https:&#x2F;&#x2F;queue.acm.org&#x2F;detail.cfm?id=3447806</a><p>It discusses many of the same trade-offs, but reaches different conclusions. It is true that frameworks are not for everyone, and their benefits are likely more pronounced in larger organizations.
SkyMarshalover 2 years ago
This is a beautiful blog. Love the typography and layout and readability. Looks like Jekyll fwiw [1].<p>[1]: <a href="https:&#x2F;&#x2F;github.com&#x2F;berkes&#x2F;berkes.github.com" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;berkes&#x2F;berkes.github.com</a>
评论 #33188908 未加载
woranlover 2 years ago
Frameworks come and go. What is trendy today will be deemed obsolete a few years later. By the time when the community no longer interested in said framework, it will feel like the rug got pulled leaving many projects stranded.
评论 #33185713 未加载
chrismellerover 2 years ago
&gt; The more isolation, the better maintainable.<p>I think sums up the entire thing. Nothing will <i>necessarily</i> harm anything, <i>but</i>…<p>If you make sure your framework and your app logic are sufficiently isolated then everyone is happy.
ladyattisover 2 years ago
I think this article sums up my experience with frameworks. It&#x27;s not to say they&#x27;re worthless but that if you use them then you should minimize how much you modify them based on your stakeholder feedback. That means communicating to your stakeholders the limitations of the framework and the costs up diverging from the framework&#x27;s structure to build a feature.
night_personover 2 years ago
Whoever insisting promoting building everything from scratch, should try to live with such home grown framework. I saw few times when after building such software, original authors left and you stuck supporting this old crap with usually no documentation. After some time you decided to leave, but your CV does not contain now magic words as Spring, Django, etc.
berjinover 2 years ago
SvelteKit made some breaking changes recently but they also had a migration script to re-write 99% of my code. I wish all frameworks did this.
jvalenciaover 2 years ago
No problem is new. You could use a facade pattern to decouple your framework. Though the extra step is often too tedious for most developers.
emsimotover 2 years ago
I was against frameworks until I used re-frame in Clojurescript. If the framework is sufficiently pluggable it can be incredibly valuable.
yi_xuanover 2 years ago
Frameworks subject to MVC pattern are logical cohesion, and tight coupled. In this respect, other frameworks, like Flask, are much better.
kazinatorover 2 years ago
&gt; <i>a software framework is an abstraction in which software, providing generic functionality, can be selectively changed by additional user-written code, thus providing application-specific software. [..] Frameworks have key distinguishing features that separate them from normal libraries:</i><p>You mean, whereas you call a library; a framework calls you? :)
seydorover 2 years ago
the real reason frameworks are a burden is that you re not allowed to edit their code. We should be able to change every bit of the architecture for whatever reasons to make it an organic , coevolving part of our project. But for this to be possible we will need AI to perform external upgrades without breaking our code
o_mover 2 years ago
Most developers only have a two year horizon, and they are always thinking about the next job. If you learn some proprietary software it will hurt your chances to easily switch jobs in the future. So you end up choosing the company that uses the framework you believe you&#x27;re going to keep using at your next job.
z3t4over 2 years ago
It depends a lot how strong&#x2F;leaky the abstraction layer is. For example nodejs and PHP are less leaky then the abstraction layers (frameworks) applied on top of them. So the more layers of frameworks stacked on top the faster it is to get a working demo, but the harder it will be to maintain.
hnarnover 2 years ago
My main issue with the usage of frameworks is when they are used in a situation where they are clearly not needed. It seems common in my opinion that people who use npm, react etc. as a part of their work -- where we can assume for the sake of argument that it is necessary -- also use these same tools for minor hobby projects they&#x27;re involved in, where it really wouldn&#x27;t be necessary.<p>I&#x27;ve seen more than one &quot;theme&quot; for example for any generic site generator or blogging software that does nothing more than set up some CSS rules, define some views and use some very minor JS for interactivity, but still has a minified output ground through npm with the almost mandatory 200+ dependencies that of course break and cause security warnings over time.<p>I&#x27;ve also seen entire products written in a framework that seemed invincible in the day it was created, only to be a dinosaur everybody despises five years later when new functionality needs to be added. Frameworks inevitably makes me think of the poem &quot;Ozymandias&quot;[1], they accumulate as dead monuments over time, and it cannot be avoided.<p>So, what to do? Well, my humble and highly personal opinion is that two thoughts should at least be entertained:<p>1) Using less code and less infrastructure to &quot;build&quot; it may, for smaller projects, make them a lot more maintainable and robust over time<p>2) For larger projects, instead of hooking your cart to one framework for everything, focus on separating the functionality into different parts, so that at least when one of your frameworks need to be replaced five years down the road, you can keep using the other separate parts that work fine.<p>[1]: I met a traveller from an antique land,<p>Who said—“Two vast and trunkless legs of stone<p>Stand in the desert. . . . Near them, on the sand,<p>Half sunk a shattered visage lies, whose frown,<p>And wrinkled lip, and sneer of cold command,<p>Tell that its sculptor well those passions read<p>Which yet survive, stamped on these lifeless things,<p>The hand that mocked them, and the heart that fed;<p>And on the pedestal, these words appear:<p>My name is Ozymandias, King of Kings;<p>Look on my Works, ye Mighty, and despair!<p>Nothing beside remains. Round the decay<p>Of that colossal Wreck, boundless and bare<p>The lone and level sands stretch far away.”
jokullover 2 years ago
The criticism is mainly on last-generation frameworks that came around before React and the like. They bundled together an all-in-one approach to writing web apps. Django comes with an admin tool!<p>The world has largely moved to richer frontends so stacks are more flexible.
zinckiwiover 2 years ago
Sure. But not using a framework will harm the maintenance of your software <i>more</i>.
abracadabra_over 2 years ago
Write small, well tested services in the easiest to use framework you can find. If the service becomes hard to maintain then replace it. This should be a simple job guided by the tests.
评论 #33189643 未加载
评论 #33188573 未加载
dotxlemover 2 years ago
&quot;[Frameworks] have different goals than you or your team.&quot;<p>Seems like if that&#x27;s the case, then you&#x27;ve selected the wrong framework more than frameworks as a whole are bad.
plaguepilledover 2 years ago
Citation needed: the blogpost. Less FUD on HN please and thanks.
personjerryover 2 years ago
Not using a framework will harm the existence of your software
NikhilVermaover 2 years ago
I see Frameworks as another layer of abstraction, just like programming languages. And they have the same pros&#x2F;cons that comes with abstractions.
default-kramerover 2 years ago
If you read far enough, this is the author&#x27;s actual complaint: &quot;Yet most frameworks come with all those details up-front and mixed up. They often make it very hard, if not impossible, to be isolated.&quot; I disagree. Very few of the frameworks I&#x27;ve used have made it difficult for me to write all the interesting parts of my app in a framework-agnostic way. A complaint I could agree with is &quot;frameworks tempt people to write too much framework-dependent code&quot;, but a purely technical criticism does not match my experience with frameworks.
pepito_fdezover 2 years ago
So many things wrong with this article...<p>But I won&#x27;t comment here. Like a good gladiator, I will eviscerate it on the public square: LinkedIn!
makachover 2 years ago
Problem with this statemetn is that it is recursive. Everything you do will end up as some sort of framework and thus, stack overflow achieved.
hinkleyover 2 years ago
I will just sit over here nodding along and not making any eye contact with anyone who mentions unit testing frameworks...
评论 #33188951 未加载
etchalonover 2 years ago
I feel like every decent developer goes through a period where they decide Frameworks aren&#x27;t worth the hassle.
phendrenad2over 2 years ago
I strongly caution solo developers away from using a backend framework. A frontend framework is necessary for modern web development. Every HN startup should be going as minimal as possible.<p>Once you have 2 or more developers, you&#x27;ll need to adopt a framework for new work (Rails, Django, etc.). Once you have 20 or more developers, you&#x27;ll have more frameworks than you can count. And that&#x27;s ideal.
adrianthedevover 2 years ago
A bit dramatic and provocative. But a nice way to go in-depth with the pros and cons of a framework.
ZikPhilover 2 years ago
I think his website could use a framework and some off-the-shelf templates to make it easier to read :)
评论 #33186178 未加载
raydiatianover 2 years ago
&gt; Using a Framework will harm the maintenance of your software<p>“Time will harm the maintenance of software.”<p>Simpler, more correct.
adenozineover 2 years ago
Capitalizing Framework in the title made me think this had something to do with those laptops…
bradwoodover 2 years ago
Here I was thinking this was a knock against the Framework laptop offering <i>dho</i>
stevenallyover 2 years ago
I always preferred libraries. But they don’t seem to exist for web development.
tbrownawover 2 years ago
So, frameworks are bad, <i>unless</i> you follow standard advice about loose coupling?<p>I&#x27;d think most things would be bad if you failed to follow that advice about them, and the frameworks I&#x27;m most familiar with (aspnet core, ef core) seem to be pretty good about making it easy to follow.
评论 #33187553 未加载
efficaxover 2 years ago
you either use a framework or you end up writing (a bad, usually) framework
eezingover 2 years ago
Not using a framework will harm the maintenance of your software.
revskillover 2 years ago
Use of framework to me is a prove of lacking of knowledge for self-control.<p>Framework is a debt, not an asset.
quantum_stateover 2 years ago
It’s not even wrong …
knodiover 2 years ago
Without a framework whats the alternative? Roll your own everything...?
评论 #33186180 未加载
评论 #33188571 未加载
edf13over 2 years ago
No, it won’t
quickthrower2over 2 years ago
tl;dr: NIH
评论 #33187556 未加载