3 ms·
That is putting the cart before the horse. Frameworks solve for a fundamental business problem well before ever approaching any technical problems. A front-en
by austin-cheney 3y ago
That is putting the cart before the horse. Frameworks solve for a fundamental business problem well before ever approaching any technical problems. A front-end framework is an architecture in a box, a pre-designed composition. There are a couple of business reasons for that:
1) Provides a common externally defined abstraction, so that developers require less training and are more disposable.
2) Supplement skills of unskilled developers
The reason frameworks do not primarily solve for change detection, is because the browsers already provide that. Frameworks provide an additional solution riding on the browser's solution as an abstraction. Framework don't even really solve for a common set of standards either, because the browser provides that too. I really want to say that major frameworks provide for a more narrowly construed set of APIs and design approaches, but the APIs on modern frameworks are absolutely massive, so I cannot say that either.
So... frameworks are really just an abstraction to achieve a particular design approach, whether good or bad.
- whatshisface 3y ago3) Saves you from having to rewrite dataflow and state management code with every project. (Saving time is a business factor.)
- austin-cheney 3y agoThose are trivial to solve for and then once you do solve for it its just a matter of copy/paste from project to project with about 10 minutes of rewiring. That costs dramatically less than spinning up a large framework project to project, but frameworks save on training time because most developers cannot solve for these problems on their own.
- deleted 3y ago[deleted]
- quest88 3y agoYou're describing an inhouse framework
- austin-cheney 3y agoThat 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 agoWhat 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 agoComponent 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?