What differentiates front-end frameworks
1–10 of 256 posts
Re: What differentiates front-end frameworks
#2> Instead, we’ll go directly to the crux of the main problem front-end frameworks set out to solve: change detection, meaning detecting changes to application state so that the UI can be updated accordingly. Change detection is the fundamental feature of front-end frameworks, and the framework authors’ solution to this one problem determines everything else about it: developer experience, user experience, API surface area, community satisfaction and involvement, etc., etc.
I disagree. Sure that's at the core of how a framework is written, but all the developers really care about are the interfaces. The user doesn't care at all unless it doesn't work or is annoying to use.
If your interfaces are dictated by the way the event loop is written, there's something wrong that needs to be decoupled. Events should be generic and interfaces should be arbitrary to what developers want.
Re: What differentiates front-end frameworks
#3What about Solid.JS?
Re: What differentiates front-end frameworks
#4> Instead, we’ll go directly to the crux of the main problem front-end frameworks set out to solve: change detection, meaning detecting changes to application state so that the UI can be updated accordingly. Change detection is the fundamental feature of front-end frameworks, and the framework authors’ solution to this one problem determines everything else about it: developer experience, user experience, API surface…
Since it's at the core of how a framework is written, it affects what the developers must handle and therefore the interfaces that are possible. If you know how a framework handles change detection, you already know something about the interface it must expose.
Re: What differentiates front-end frameworks
#5can't forget library support.
Re: What differentiates front-end frameworks
#6QML wins with bindings and signal and slots! (In this example the the text property of the Text componenet is binded to count, so whenever count changes the text changes).
```
property int count: 0
Button { onClicked: { count--; } }
Text { text: count.toString(); }
Button { onClicked: { count--; } }
Button { onClicked: { incrementLater.start(); } }
Timer { id:incrementLater interval: 1000 onTriggered: { count++; } }
```
Better in so many ways.
Re: What differentiates front-end frameworks
#7That 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.
Re: What differentiates front-end frameworks
#8That 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 u…
3) Saves you from having to rewrite dataflow and state management code with every project. (Saving time is a business factor.)
Re: What differentiates front-end frameworks
#9Not a frontend person, and unlikely to become one anytime soon, but maybe someone can shed some light into the downsides of Svelte? The article fails to mention any (it's apparently "win-win"). Presumably if Svelte were the be-all-end-all of front-end frameworks, it would dominate soon enough?
Re: What differentiates front-end frameworks
#10That 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 u…
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.