"Facebook has done a good job of deprecating and warning for the last few months, but not all libraries are well-maintained and if you depend on or have forked a great many ancient ones, you will be in for a bit of a slog.").
This is one of reasons to limit third party libraries you use along with React. Every dependency comes at cost. If you use React and React-Foo, React-Bar, React-Baz and dozen of other React based additional libraries, then upgrading all/troubleshooting can be painful. As it was ("We ran into an error which took us 2 days to track down to a library, ...")
Agree 100%. I always use zero-dependency libraries if they are available. The only library in my codebase that has a React dependency is react-redux. React upgrades have thus far been painless.
> it makes sense to start cleaning up the codebase.
This is very optimistic assumption that people will actually clean the codebase at some point. From what I've seen technical debt can stay very long time. Temporary hacks can become permanent.
Spikes/prototyping can be quite effective, but to be effective in writing spikes/prototypes a team must be disciplined to rewrite/refactor later. And from my experience teams are often not very disciplined and pile of spaghetti code begin to grow...
> The problem with this approach is that if the tech debt
> catches up with you faster than you can figure out the
> product-market fit. In this case it gets harder and harder
> to move and instead of going faster you go slower
Yeah. This is what I've seen. Even in startups quick and dirty code can be developed over months. And in such long time pile of spaghetti just piles up (people can make quite a mess in days. Imagine what they can do over months...).
Like they say "There are only two hard things in Computer Science: cache invalidation and naming things." ;) Apps without `refresh` claim to be ones which managed to solve caching problem properly (they usually didn't anyway)
Indeed. Often they don't even realize they're in the caching business. And yet, showing the state of anything for which the canonical representation doesn't live in your process' memory is caching state.
Actually it's quite opposite. Redux is a library which was created not until 2 years ago and it is used only in JavaScript. Actor model and similar message-passing patterns are in use for decades and not only in JavaScript but in many programming languages. They are popular e.g. in game development for communicating between game objects.
There is this weird viewpoint in JS community that world is turning around JS and its ecosystem, and this is the newest popular library that dictates standards rather than decades of CS knowledge ;)
Based on what shows up on the front page, I'd say the average reader is way more likely to be familiar with Redux than the actor model.
I never said Redux dictated the standard, I simply asked for the differences, and if it weren't for boobsbr's response, I'd be stuck in a state where I don't know how close Redux was to this model which is quite important to get context and understanding.
> There is this weird viewpoint in JS community that world is turning around JS and its ecosystem, and this is the newest popular library that dictates standards rather than decades of CS knowledge ;)
If you criticize people like this for not knowing what came first, then it's no wonder people feel like that because you'd never give them the opportunity to learn about the lineages. Instead, people will simply think "oh this looks like an interesting paradigm, maybe I'll consider using it in my next project" without realizing that they're already using it.
> I think it really helps with maintenance and scalability of
> projects down the road and saves you time later on.
It's popular argument but I don't think it's completely correct.
On the one hand principles of Redux (immutability, message-passing approach, separation model from the view) can be helpful, on the other hand huge amount of boilerplate and moving parts can only spoil scalability.
Besides Redux is very low level with very little abstraction (this is why some many abstractions over Redux appear - because Redux alone has almost none).
I think Redux has good foundations but it's poorly designed as a library targeted to average developer working on real projects. It feels more like some academic experiment, something more like proof-of-concept that library that solves real problems in elegant way.
I've created library `transmutable` for performing automatic copy-on-write behavior in JS (you just write imperative code which is transformed behind scenes into immutable updates
https://npmjs.com/package/transmutable
This can avoid boilerplate traditionally associated with immutable updates in JavaScript, because you just write
I think many things could run in a browser. All GUI,
whole visual layer could run in a browser (maybe except system menus, but they could be recreated in HTML/CSS). All business logic also could run in browser.
Of course there are some other things won't run in browser, for example file system access (but this could be emulated by some kind of virtual file system). Or native NodeJS extensions (if application uses these). Or some system calls.
But these parts (not-compatible with browser) should be isolated from the rest of application and either ported somehow into the browser or just disabled in the browser version.
What I see is something else - projects are written in sloppy way, with bad architecture, where there is no respect for Single Responsibility Principle whatsoever. They are just written in non-portable way (it's matter of architecture rather than technology).
This is one of reasons to limit third party libraries you use along with React. Every dependency comes at cost. If you use React and React-Foo, React-Bar, React-Baz and dozen of other React based additional libraries, then upgrading all/troubleshooting can be painful. As it was ("We ran into an error which took us 2 days to track down to a library, ...")