Ask HN: Why do we need frameworks like React, Vue for front end developments?
What's the purpose of these frameworks? Do we sacrifice performance for ease of development?
4 comments
HTML/DOM/CSS/JS was not intended for application development. Web Components are a modest attempt but you still need a framework. These frameworks give you higher abstraction and a decent architecture that scale. Ease of maintenance is also an important factor.
You will not necessarily sacrifice performance. Well, written react application might perform better: fibers, virtual dom, synthetic events, pure components and async rendering are decent optimizations.
You will not necessarily sacrifice performance. Well, written react application might perform better: fibers, virtual dom, synthetic events, pure components and async rendering are decent optimizations.
The area that I know about is the challenge of asynchronous communication.
That is, when a web application makes a request to the server, the response is not returned to the caller but is instead to delivered to a callback function which may or may not get called later.
Because you don't know what order callback functions get called in there is plenty of room for "race conditions" but you don't have the tools that you would use to manage these in a multithreaded environment or multiprocess environment.
It is simple to autocomplete form results without a framework, but if you have some kind of GUI where doing something somewhere might have effects on other parts of the screen you have to route information from the callbacks to all the stuff that has to be updated it will drive you crazy, not to mind the relationship between initializing UI components vs updating their content, how to implement caching (tricky when returning directly with a cached result as opposed to a callback causes a "race condition"), etc.
All of this is pretty manageable if you have a systematic approach to how communication updates the UI, and that is something most front end frameworks provide.
There are other issues such as cross-platform, configuration management, build (cut away junk and compress to speed up the site) and working around performance problems with web browsers, etc. that frameworks also address, somebody else can give you a better answer for that.
That is, when a web application makes a request to the server, the response is not returned to the caller but is instead to delivered to a callback function which may or may not get called later.
Because you don't know what order callback functions get called in there is plenty of room for "race conditions" but you don't have the tools that you would use to manage these in a multithreaded environment or multiprocess environment.
It is simple to autocomplete form results without a framework, but if you have some kind of GUI where doing something somewhere might have effects on other parts of the screen you have to route information from the callbacks to all the stuff that has to be updated it will drive you crazy, not to mind the relationship between initializing UI components vs updating their content, how to implement caching (tricky when returning directly with a cached result as opposed to a callback causes a "race condition"), etc.
All of this is pretty manageable if you have a systematic approach to how communication updates the UI, and that is something most front end frameworks provide.
There are other issues such as cross-platform, configuration management, build (cut away junk and compress to speed up the site) and working around performance problems with web browsers, etc. that frameworks also address, somebody else can give you a better answer for that.
Almost all software development tools sacrifice some speed to gain some ease of development, otherwise we would all write Assembly.
Whether the tradeoff is worthwhile depends on your needs, including your team size, product complexity, and user preferences.
For most of us, writing vanilla JS will eventually waste more time than it's worth.
(Nitpick: React is a library, not a framework, that ideally replaces boilerplate/reptitive code with a simple API. In practice, it doesn't always work that way, though.)
Whether the tradeoff is worthwhile depends on your needs, including your team size, product complexity, and user preferences.
For most of us, writing vanilla JS will eventually waste more time than it's worth.
(Nitpick: React is a library, not a framework, that ideally replaces boilerplate/reptitive code with a simple API. In practice, it doesn't always work that way, though.)
agreed that Angular and React are more trouble than is needed
Vue provides the right amount of helpfulness vs. flexibility. As simple as jQuery but with the power of a full framework
Vue provides the right amount of helpfulness vs. flexibility. As simple as jQuery but with the power of a full framework