hex13

"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, ...")

besides - if you generate your SVG programmatically you can just return them in your render function:

function Foo(props) { return <svg> <circle cx="10" cy="10" r="100" /> </svg> }

> Once the product-market fit is achieved (...)

> 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)

> I simply asked for the differences,

One of differences could be that Redux has only one object("actor") which can receive messages - that's store.

In actor model there are many actors which can both receive and send messages.

> since Redux is much more prevalent.

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 ;)

Redux is a chicken, actor model is an egg. Similar patterns were used decades before Redux was even born.

> 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 never understood why to run Slack as desktop app if Slack can be run in a browser with the same GUI and features. Am I missing something?

> In practice, though, very little code

> written for Electron will run in a browser.

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).