3 ms·
I've settled on one maxim when it comes to evaluating new technologies: there is no free lunch. In real projects there is always fundamental complexity. Where w
by munchbunny 6y ago
I've settled on one maxim when it comes to evaluating new technologies: there is no free lunch. In real projects there is always fundamental complexity. Where will that fundamental complexity go?
If a new framework/library/paradigm comes in looking really hyped up and cool, my automatic question is "well what's the catch?" There always is a real caveat in there somewhere. Usually the new shiny thing solves one class of problems at the cost of making a different class of problems harder to solve. The important question isn't what the shiny thing makes easier, because everybody and their grandmother is telling you what that is. The important question is what that shiny thing makes harder.
React, for example, is awkward for continuous, time-stepped state (games) because what you see is an interpolation of many objects transitioning between many states. It's not that the abstraction can't work, it's that it's a clumsy one to apply. Thankfully the vast majority of web apps don't have this issue, so it's usually fine, until you try to make something real-time.
Same story with NoSQL databases. The canonical issue there is that joins are much more expensive. So how much do you need those joins? Turns out some non-trivial number of scenarios are fine without joins, but for CRUD apps, turns out a substantial number of things are easier with joins.
- duxup 6y agoI think you, unlike the writer, would seem to wish to put the time into evaluating. The article though takes two pretty low cost / easy to use bits of tech (fetch, hooks) ... and relegates them to being "trends" without really evaluating them.