5 ms·
This reminds me of that Netflix talk on React [1]. In it, the guy first praises React to the heavens, then spends the rest of the session explaining all the wa
by et1337 11y ago
This reminds me of that Netflix talk on React [1].
In it, the guy first praises React to the heavens, then spends the rest of the session explaining all the ways they had to disable and work around React to get what they wanted with decent performance.
It seemed to me like their use case could have been done with jQuery in a few hundred lines. Maybe I missed something.
[1] https://www.youtube.com/watch?v=g01dGsKbXOk https://www.youtube.com/watch?v=g01dGsKbXOk
- igorgue 11y agoNah you got the point, all these JavaScript frameworks are just over-engineering.
- deleted 11y ago[deleted]
- SonicSoul 11y agojust curious how you arrived at jQuery comparison. isn't that just a library for DOM utilities while react is a view engine optimized for minimum dom manipulation using observable pattern?
- et1337 11y agoI made the comparison because at the beginning of the video, he talks about how they split into two teams; one used jQuery and the other React. Apparently the jQuery team moved significantly slower. I found that hard to believe given all the hacks they had to with React later on.
- tiglionabbit 11y agoThe React team was probably quicker at responding to the designers' ideas. The stuff that took a longer time was getting all the transition animations to work, which can be difficult in any higher-level framework.
- qudat 11y agojQuery and React are DOM manipulation libraries. jQuery packaged a bunch of other stuff in it but at its core it is all about DOM manipulation.
- qudat 11y agojQuery and React are DOM manipulation libraries. jQuery packaged a bunch of other stuff in it but at its core it is all about DOM manipulation.
- tiglionabbit 11y agoHe praises React because it makes it easy to change the UI design at any time in response to new requests from the designers. The hard parts he talks about are animations, pre-loading, and virtual rendering, which require some higher level orchestration to get right in any framework. You have to have some component keeping track of this stuff. They mentioned that they had to extend the standard transition component to make it more reliable. He also talks about writing code in a way that will work on both the server and client side, which is something you have to think about no matter what library you're using.
- et1337 11y ago> He praises React because it makes it easy to change the UI design at any time in response to new requests from the designers. Does it though? I suspect their system is fairly brittle after all that "higher level orchestration". I keep seeing this pattern repeat in different software disciplines. Unity is the same way: fantastic for prototyping, but often more painful in the long run. It reminds me of a wise saying (can't remember the source) to the effect of this: Javascript library user, day 1: "So expressive! So elegant! So easy!" Day 300: "Kill me now." C++ library user, day 1: "How can anyone live this way?" Day 300: "Whoever wrote this was actually pretty smart."
- tiglionabbit 11y agoThis conversation could be had about any abstraction. They help with some things and hinder other things. In this case, a purely functional transformation from application state to HTML means you don't have to think about every possible transition between states like you would in a normal jQuery application. However, since you are not thinking about transitions, implementing transition animations will be harder.