Comment by austin-cheney | Hacker News Reader

Comment by austin-cheney | Hacker News Reader

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.

3) Saves you from having to rewrite dataflow and state management code with every project. (Saving time is a business factor.)

Those 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.

You're describing an inhouse framework

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

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?

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?

Reply on news.ycombinator.com