10 ms·

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

• 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.
  • Supermancho 4y ago
    > Not all software has an implied framework within it. The definitions of "framework" are always a sticky issue. If you take "framework" at face value, it's minimally a set of idioms. "an essential supporting structure which other things are built on top of" - which necessarily includes a mental model of execution. This relates closely to why naming, in software development, is considered so difficult. All software has an inherent framework. First is the mental model and then the implementation. Implementation middleware to simplify utilizing these idioms or enforce them, are incidental. If you're lucky, you can derive some of the underlying design from documentation. Ironically, those who claim that they never use a framework are largely making implicit claims about what they consider a framework to be or have.
    • inopinatus 4y ago
      Well, I don't disagree, and we could almost label that "framework zero", and also hence the reference to Unix utilities and their assumptions regarding stdin/out, but I am also taking a contextual cue from the article linked at the top which is clearly taking aim at large pre-chewed boluses of code such as Rails, Django, Drupal and so forth. I am just about old enough to have even toggled in a program on the front panel of a PDP-8 that my local university had kept around to occupy valuable floor space in their computing center. I wouldn't say I used a framework, but I was just a kid at the time, so it's possible that I did use a stepladder.
      • hmlongco 4y ago
        Really? Did my toggling on an 8e that ran as a controller for a COM (Computer Output Microfilm) "printer". Not saying that I could write code directly in octal... but I was pretty darn close. Of course, it helps when your assembly language consists of just eight instructions.
    • vidarh 4y ago
      > The definitions of "framework" are always a sticky issue. Hence why the article defines what it means by framework, and by the definition in the article, software rarely has any implied frameworks within as one of the definition points is that there is code in the framework the user is not free to change. There certainly can be frameworks emerging within large projects, but by the definition in the article they're not problematic because they don't lock you in: You can change those pieces. You in particular ultimately remain in charge of the flow of control in the code. Those "frameworks" don't take away control and put you in a straightjacket. The article could perhaps have been framed better as "how to write a framework or framework-like thing which doesn't become a problem". Some thoughts might be: * Structure it as decoupled components where you can opt in and opt of different elements, including of control flow. E.g. Padrino - a Ruby web framework fits well here. You can pick and choose which ORM to use; you can opt in to a router, controller, admin interface, mailers, logging, caching, and view libraries, or not use them at all. You can start with plain Sinatra and add in bits of Padrino as and when you choose, or supply your own. * In particular, if possible, externalise the control of flow into replaceable components. Doing this alone can often be enough to get you out of the straight-jacket of "frameworks as defined by the article" * Allow users to override/replace all components rather by defining clear interfaces and not assuming you can call hard-code calls between the different components. Padrino again fits well there. So did e.g. Qmail treated as a "framework for building a mail server" ("nobody" used pure Qmail, but Qmail defined the interfaces between each individual program which made up the full system, so you could replace every single bit step by step). In particular there should be no "magic" glue which there isn't a well defined way of tearing out.
• johnfn 4y ago
  > This sentiment sounds correct in theory, but it isn't based on any experience from any one of the people making such a claim. Do you really think that there isn't a single person who claims that frameworks are good who has never written an application without one? Well, now you know me. I've tried writing a website without React, and I ended up writing a buggy half-implementation of React. (In my defense, I didn't really know of React at the time.) You only really have to do that sort of thing once before you learn that frameworks have some advantages.
  • throwaway0asd 4y ago
    Your comment appears to reaffirm the consequent. Your comment suggests you tried to not use a framework once, but failed only to write a bad framework, which suggests you are incapable of writing code without frameworks. Is there something more to draw from this?
• tbrownaw 4y ago
  A framework is what happens when you write a ton of similar apps and factor out the common parts. The quote here is no more literally true than the original lisp quote, but (just like the original) that doesn't stop it from being true in spirit.
  • valenterry 4y ago
    If that were true, what would be the difference between a library and a framework? Is a library not also factoring out common parts? Or is a framework just a bunch of libraries? No, this definition doesn't describe what people understand as frameworks.
    • bulatb 4y ago
      Maybe common structure, not common parts. "Framework" is a good description: it gives you the shape, you fill it in.
      • valenterry 4y ago
        Care to elaborate the difference? In both cases common code is extracted.
        • Ma8ee 4y ago
          The difference between a framework and a library is that you call the library, while the framework calls your code.
        • vidarh 4y ago
          The article includes a crucial point about inversion of the flow of control. Somewhat exaggerated: You call into a library; a framework calls into your code. The old archetype of a framework might be one which expects to control an overall event loop for your application. In practice many things we would still recognise as frameworks allows you to undo that, but I still think it's a useful rule of thumb in that even many frameworks which technically allows you to remain in control of the overall flow tend to assume the framework will mostly dictate structure and flow.
• garyrob 4y ago
  "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." Twice, I made the mistake of programming my own data frameworks so that I wouldn't have to rely on pre-existing databases. Total mistake both times. I have learned my lesson. (Most people wouldn't even think of doing that now; but I've been a pro since the 80's. The situation with web frameworks now is analogous in many ways to the situation with databases long ago.)
• scarface74 4y ago
  > 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 I also have 25 years of experience and started my career writing C and FORTRAN on mainframes without any real library let alone a framework and then wrote my own libraries in C for my next job where I had to write cross platform code that ran on x86 based PCs and mainframes. My next job, involved maintaining a proprietary compiler/IDE/VM for ruggedized Windows CE devices. So I think I have experience working without frameworks. Not to mention by the time I graduated from college in 1996 , I was a hobbyist assembly language programmer on 4 processors for 10 years (65C02, 68030, PPC 601, x86) I can say that it’s the fifth level of hell coming behind an “architect’s” half assed framework who thought their problem was so special that they didn’t want to use a mainstream framework to handle non business specific concerns. There have been a few times that I have ripped out my own code in favor of a popular library when I discovered it.
  • jstrong 4y ago
    > There have been a few times that I have ripped out my own code in favor of a popular library when I discovered it. I'm much more likely to rip out the one function I need out of a framework or library and put it in my code, with a comment "// stolen from <source>". I've spent lots of time untangling the crux of someone's implementation away from the problematic abstractions they built up around it to make it universally adaptable.
    • ldng 4y ago
      And of course you regularly check back for bugs and security issues, right?
      • snovv_crash 4y ago
        Usually the security issues come from the wrapper code that tries to hammer the square peg of an algorithm into the round hole of the abstraction they provide. Dropping the wrapper code is the safest thing you can do.
• pmontra 4y ago
  Sometimes I stated writing a web app with Sinatra, which is about the less frameworkish thing you can do in Ruby unless you are also writing your own router. I regularly end up having to 1. Either write my own code to query the db and build Ruby objects from the response and viceversa OR use ActiveRecord. 2. Same thing about managing the database schema. Either my own code or someone else's. So why not Rails' well tested one? 3. Organize the code base in some way that makes sense. 4. Write my own code to manage tests OR use rspec / capibara (OK, they are not part of a framework but they are a large dependency) In the end I always regret I didn't use Rails from the beginning because I end up spending a lot of time doing useless takes. Keep in mind that I do that for my own projects in my free time. 99% of the times my customers decide what to use (Rails, Django, Phoenix.)
  • vidarh 4y ago
    Here's another view on using Sinatra: * It lets me pick and choose an ORM. I usually prefer Sequel over ActiveRecord. Pretty much nobody suggests you should use Sinatra without an ORM unless you genuinely don't need a database. * Nobody suggests you should build your own schema management. Pick an ORM which provides it out of the box (e.g. Sequel), or use a component which provides it (e.g. Padrino has a generator component which out-of-the-box supports generating migration helpers for the major Ruby ORM's and some you're unlikely to have heard of) * Nobody suggests you should write your own code to manage tests. Just use rspec / capybara, or whatever else you prefer. And again, consider using Padrino's generator if you want something to generate scaffolding for it for you. The point of using Sinatra is the freedom to opt-in to your preferred components as and if/when needed. If you always want the ones Rails provide, just use Rails, nobody will think less of you for doing so. Not even those of us who personally don't like using Rails. For my part I rarely want the ones Rails provide, and so I rarely use Rails. Often I use bare Sinatra. Sometimes I mix in some components from Padrino because they can be easily torn out again. I'd suggest that if you want something lighter than Rails but have those issues with Sinatra, look at Padrino (Sinatra + a pre-packaged set of components you can opt in or out of separately, or layer in piece by piece on top of Sinatra if/when you need them). But you can also just use Rails.
  • wink 4y ago
    Counterpoint, and let's assume mostly parity of flask :: sinatra and rails :: django. I've usually used Flask and even when I needed a few db operations you could easily contain that to a small part of the code and stepping up to django would have felt like a huge step up in complexity. But I guess it really depends on what you're actually writing - your use case sounds a bit like "something like wordpress" from a "customer uses this" point, and mine were mostly "small REST API endpoint for something".
• m00x 4y ago
  Maybe you should master your tools before using them. You can use frameworks where they fit, and not where they don't. Knowing when to do which takes time and experience, but it is definitely do-able, and better. Frameworks allow you to update, and maintain your app for free, since others will do it for you. If you do it yourself, you have to do all the work and that's keeping you from adding value elsewhere. To not use frameworks these days would be objectively stupid unless you're working on extremely low-level things.
  • BlargMcLarg 4y ago
    >since others will do it for you That's the big caveat. Loads of frameworks leave clear issues dead in the water. Your team/predecessors weren't the most clean. Now have fun fixing that one issue working out a framework you can't easily modify or switch out. Of course that problem isn't unique to frameworks nor inherent to framework rather than social and legal problems.
  • xnzakg 4y ago
    > Frameworks allow you to update, and maintain your app for free, since others will do it for you. Usually not for free. Sooner or later there's an API breaking change and you end up spending time reading changelogs trying to figure out how to get your code working again...
    • m00x 4y ago
      Still way more work to do all of that yourself.
  • Ialdaboth 4y ago
    The voice of reason. Frameworks just work for a reasonable cost, offer an easy upgrade pathway to follow, and facilitate the integration of new devs. In most case (depending of your business domain, of course), they should be more than adequate. The cold hard truth is that most developers are not the genius hackers they fancy themselves to be.
  • throwaway0asd 4y ago
• piokoch 4y ago
  Where do you draw the line between using and not using framework. Programming language is a framework over machine language. Java garbage collector is a wrapper around manual memory management. Java Servlets is a pretty thin wrapper over HTTP request/response, is this a framework already? How about Java JAX-RS, it is built on top of Java Servlets and built to handle mostly REST type requests. Same with database connectivity. Where framework starts? On JDBC/ODBC driver layer? ORM mapper like iBatis? JPA/Hibernate "true" ORM with automatic dirty checking?
  • planede 4y ago
    For me the most important defining characteristic of a framework is inversion of control. With a framework high level control flow is dictated by the framework itself. It follows from this that using two different frameworks can be challenging. An abstraction layer over a database is not necessarily a framework, it can be just a library. I'm not familiar enough with specific ORMs to comment on those. A programming language is interesting to look at from this point of view. While sure, you need to use the programming language's features to implement control flow, it typically doesn't actually dictate a high-level control flow itself. There are probably languages where this is not completely true.
    • NoGravitas 4y ago
      By this definition, though, which does seem to be the one used by the article, both Flask and Sinatra are frameworks. Which I don't necessarily disagree with, but there are tons of people here in the comments arguing the opposite. For that matter, it seems to me that CGI would be a framework in this sense - the high level control flow is that you are called by the web server, run, take input from environment variables, output an HTTP response, and exit. Not fundamentally different from "Django views take a request object as an argument, and return a response object, and are called by the framework". Just a matter of degree.
  • throwaway0asd 4y ago
    It appears you are falsely using the word framework to describe abstraction. Language is not a framework. APIs are not frameworks. A framework is a tool providing conventions that dictate exactly how to proceed, typically demonstrated as a packaged architecture. The appeal, it seems, is not having to independently form many minor decisions. It appears bias, and possibly even neurological limitations, largely account for framework dependence. Typically this is self evident when you step back and examine the opinions qualifying that dependency as most such arguments are fallacies from ignorance. Decision avoidance is the primary indicator of ASD. For example many of the arguments in favor of frameworks will sound something like: ”I tried without a framework once and produced a framework anyways, so therefore you must use a framework”. Another example: ”The code must broken and slow if not using a framework.” Without evidence (numbers) this is a bias (or a lie). Before making that claim there is likely no performance measure or comparative defect count. In my experience doing this for 25 years rarely measure anything and instead invent assumptions to qualify whatever opinion they want. Example (look at the parent and peer comments for comparison): https://news.ycombinator.com/item?id=33004060 https://news.ycombinator.com/item?id=33004060
• matharmin 4y ago
  In my current job, I have written a small framework. It's very limited in scope and hasn't changed much since the initial implementation, so it works fairly well. But, there is a big issue with getting other team members to understand how to use it. That alone is enough that we're replacing it soon. Another team member has developed frameworks for both infrastructure management and creating services exposed over http. Here there is a large value in using the same internal tooling over 20+ projects. But once again, being an internal-only tool means that the documentation is severely lacking, and often we need new features in the frameworks. All of that is essentially blocking on the single team member. In this case we're keeping the frameworks, but it definitely has its caveats.
  • throwaway0asd 4y ago
    I am a big believer that the primary business benefit of frameworks is that they ease hiring (candidate selection). There are pros and cons to that. Where I currently work they primarily rely on nontechnical qualities for candidate selection because they are more interested in choosing the right people than a tool user. Either way they will be investing time in training in some form and would rather that training focus on the business objectives than the technical objectives. Counter-intuitively I was entering the code earlier here than at previous employers even though I am writing in a language I have never touched before. This is likely because I entered this employment drowning in deliberate one-on-one training.
• treeman79 4y ago
  I’ve written without a framework several times. Pretty soon realize I’m spending my time writing up a framework. I’ve inherited non framework projects many times. They take way more time to get up to speed on. Now I’ve seen framework projects where they clearly didn’t try and work with it. Those ones just make me sad.
• RunSet 4y ago
  I think of frameworks as running with crutches or cycling with training wheels. People interview potential couriers, look them in the eye, and ask: "DO you run with crutches?" Not "CAN you run with crutches?" (as anyone who can run without crutches can run with them) but DO you run with crutches, as though running without crutches might signify a lack of ability. Fine time to unask the question.
• theknocker 4y ago
• schwartzworld 4y ago
  > have not actually experienced writing an application without a framework There are a lot of different types of organizations, and their needs for development vary. Using well known tools reduces onboarding time, and in a large organization with turnover, that's not an insignificant cost. You really think the documentation you wrote for your app is better than those of a popular open source framework? Frameworks also bring community defined best practices and standards. There is support from tooling like test frameworks that make functional / unit testing easy, linting and code formatting tools, IDE support, autocomplete snippets, debugging tools, browser extensions. These things might not be important in a small team, but with 100 devs, they bring real benefits. > I just put all my state data in one object, save it on each user interaction The saying is any "sufficiently complex app", and your approach to state management speaks volumes about the scale and type of front end apps that you work on. If you've never had bugs in your state using this strategy, it's wonderful. But if there were 100 of you constantly adding to and changing this global object, do really think that would be manageable? How much state are you dumping in this object? If you only reference it on page refresh, your app must not be very reactive. One UI component could have quite a bit of state associated with it. One complex dashboard SPA could have hundreds of different pieces of state that are being tracked. Modern frameworks are tackling that problem, and the fact that you don't have it doesn't mean nobody else does.
• jameshart 4y ago
  Any time a piece of software abstracts a repeatable pattern, that’s a ‘framework’. All a framework means is that there is a coherent, repeatable model for implementing the building blocks out of which the application is built. Even a simple command line program with hardly any functionality soon runs into the issue of having more than one command-line argument or environment-variable based configs. And a sensible, maintainable approach to this involves someone spotting ‘hey! We can abstract the bits that all our command-line parameters have in common so processing them all is consistent’. And then you have a framework. Because now ‘adding a new command line parameter’ has to be done in the standard way - you register a validator here and you add a help string there. Building something without a framework is a rejection of patterns, or of the value of establishing repeatable structure. Software that facilitates encapsulating chunks of functionality as standard building blocks is more maintainable over time. It’s much easier to work on a system where you can take a user story and interpret it as ‘okay, so we can implement that as a new Task type and then add a Tool to the Tool Library that lets users who have the right Role create a Schedule to run the task’. any time a system is sufficiently structured that you can think that way, it’s essentially become a framework. Frameworks can be lightweight or heavyweight, sure, and they can be open to being overstepped or closed - and choosing when to prefer to structure your framework to make it easier or harder for someone to step outside the lines is just an engineering choice like any other.
  • account-5 4y ago
    > Any time a piece of software abstracts a repeatable pattern, that’s a ‘framework’. With that definition all programming languages are frameworks. The first part of the article defines what the author means by a framework, which is different from libraries, and programming languages in general.
    • thomastjeffery 4y ago
      No, programming languages exist in a different domain. The domain of frameworks is explicitly in toolchains and environments. It's similar to the difference between function and algorithm. The former is literally code, and the latter is conceptual. Many programming languages are distributed with a cohesive framework. For example, Rust is distributed not only with rustc to compile binaries, but also with cargo to manage library dependencies. That doesn't prevent you from using rustc without cargo, though, or even making another rust compiler for GCC, and using GCC's framework.
• ChrisMarshallNY 4y ago
  > This sentiment sounds correct in theory, but it isn't based on any experience from any one of the people making such a claim. I've written a number of frameworks, plugins, and extensions, and refactored existing ones. I've used a number of them. I tend to customize stuff, which isn't always conducive to using "heavy" frameworks. I've enjoyed "bald" ones. Done some big stuff. Some came out great ... some ... not so great. The "not so great" stuff tended to be early in my career. Refactoring existing ones, helped me to learn how to do it right. I think the first one that I refactored, was PHP Nuke. It emitted terrible HTML, and my refactoring made sure the output would validate (and WAG the dog, so to speak). I ended up binning it, when they did their first upgrade. Learned a harsh lesson, there. I wrote a framework in Perl. That was ... challenging. These days, I tend to use a lot of modules and connectors, and use whatever framework is built into the OS (I write native Swift). I've heard great things about Laravel, but I have never used it.
• mattgreenrocks 4y ago
  > So really this isn't a question of the software, but of the developer's capability to perceive (or not) that software. It is quite telling of HN's audience if they honestly think that "every sufficiently complex framework-free application contains a [buggy] half-framework." The precise definition of a framework may be a bit hard to pin down, but most any experienced practitioner knows it when they see it. Things I look for: * coupling of a blessed architecture, libraries, and patterns. Some choice of libraries may be allowed, but they must conform to a framework-prescribed interface. * difficulty of isolating behavior for fast unit testing when using framework as prescribed (not always, but this is right more often than I want still) * inversion of control as a core building block instead of straightforward composition. (This point gets fuzzier in callback-centric langs.) * main() (or its moral equivalent) ends up being a framework bootstrap call, or is hidden entirely. * related to last points: emphasis on hiding as many execution details as possible to present a simplified view of what the framework author believes is important. * reliance on extension points to customize behavior (via subclassing/hooks) rather than simply exposing primitive operations that users can call alongside custom code. * documentation beyond API docs and tutorials, usually necessitated by the number of novel concepts introduced by the framework * heavier-than-normal emphasis on marketing, often leading with social proof from a megacorp, sometimes with big promises on how this framework is not like the others The main takeaway should be this: a framework is not something that wants to blend into the background of your application. It is extremely visible and it is something that you program to, and often must take what it wants into account when designing. Without a framework, you can literally do whatever you want, including making a huge mess, or something small, functional and minimal. I believe that should disqualify most of the rather absurd claims that all libraries/patterns/libc are "frameworks."
• taylodl 4y ago
  I've been creating software for 40 years and I can tell you the statement "every sufficiently complex framework-free application contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of a framework." is 100% accurate. Back in the day we'd go and create our own frameworks that we could use on multiple projects. They were never as robust as the frameworks that exist today since we didn't have nearly the number of people using the framework and discovering issues. Not to mention the incredible amount of time we spent creating and maintaining these frameworks. Coming from that experience early on in my career to where we are today with people complaining about "too many frameworks" sounds like first world whining to me! :) I'll take too many frameworks over having to create everything from scratch any day.