3 ms·

You're describing an inhouse framework

• austin-cheney 3y ago
  That is called Affirming the Consequent. Something like: all frameworks are composed of code so therefore all code eventually forms frameworks. It's a common form of nonsense. https://en.wikipedia.org/wiki/Affirming_the_consequent https://en.wikipedia.org/wiki/Affirming_the_consequent
  • shigawire 3y ago
    What is the difference between code you've written that you use from project to project and a framework? If it is just about the knowledge then wouldn't it be valid to just gain that same knowledge about a framework?
    • austin-cheney 3y ago
      Component isolation. * State management is merely a sum of few parts: a state artifact (a big object), a means to update that artifact, a place where that artifact is saved, and finally a function to apply state on page reload. Its an isolated system. If anything wishes to update state it just calls a function. * GUI: A window system (a big function and a bunch of supporting functions for events), content, and events specific to types of content. * File system: A call to the file system library from a user interaction, a library to recursively walk the file system on the back end, a messaging payload to communicate the requested file system details, a function to populate the file system data into DOM artifacts for user interaction. And so on. I prefer to work without frameworks because they execute far more slowly, get in the way of solving real problems (complexity), and they slow me down in writing/testing code. Writing applications isn't about how to write code. It's about organization, flow control, and just connecting the dots between a problem and a solution. Its the difference between repeating minimum literacy and writing an original inspiring novel. Why would I think some giant abstraction would save me time or improve my code?