I find myself agreeing with the article (although I also agree that it assumes you've chosen an SPA when you shouldn't have). To add my own perspective:
I work on an app, the front-end of which essentially consists of 6 nav tabs, 3 of which show an index of records with corresponding add/edit forms. We don't have any hyper-fancy interactive components that would require heavy JS libraries. And yet... we develop in React.
Yesterday, I needed to add 1 new field (representing by a checkbox input) to both our app and a corresponding back-end application we have, which uses Rails views.
I checked the git logs after to see how long each took. The Rails view took me literally 2 minutes to update (add field to model, add field to controller, add input to HAML with a class on the parent div). The React view took me 52 minutes, plus I later found out that I'd forgotten a damn type on some interface that's a shallow copy of our model.
Is this a problem with React itself? Not really. But it's a problem in the way that it's used, and our 6 nav tabs and 3 forms don't need all the overhead of React. So for people in a similar situation, this article really rings true.
Not to pile on, but I wasn't expecting your "what's this" link to be a magnet link to Discord. Could be worth specifying that, or at least using a pop-out/magnet icon beside it.
A rule of thumb I've been following lately (when communicating in e.g. GH issues or Slack messages), is to use the title of the page where possible. Hopefully, the page title should reflect the page's content, and thus automatically works as a link title a lot of the time.
In your example, I would expect the download page of Amaya to be titled "Download Amaya", so my link can simply be "If you are interested, [Download Amaya]!"
Thanks for the write-up, I feel like I understand Solid Queue quite well, now.
I suppose my primary question is: What does this do better than Sidekiq+Redis; or, why should I convert my Sidekiq jobs to use Solid Queue? I'm curious also if there are comparisons of performance anywhere.
All-in-all, though, it looks technically quite promising!
I liked your article, but I loved the design of your blog. Very clever use of colours and structuring, and the interactive demo is the icing on the cake. Nice one!
At work, I use Vivaldi's tab stacks to group tabs by the GH issue I'm working on. So the issue, PR(s), and app tab(s) go in the same stack. It's very handy.
I work on an app, the front-end of which essentially consists of 6 nav tabs, 3 of which show an index of records with corresponding add/edit forms. We don't have any hyper-fancy interactive components that would require heavy JS libraries. And yet... we develop in React.
Yesterday, I needed to add 1 new field (representing by a checkbox input) to both our app and a corresponding back-end application we have, which uses Rails views.
I checked the git logs after to see how long each took. The Rails view took me literally 2 minutes to update (add field to model, add field to controller, add input to HAML with a class on the parent div). The React view took me 52 minutes, plus I later found out that I'd forgotten a damn type on some interface that's a shallow copy of our model.
Is this a problem with React itself? Not really. But it's a problem in the way that it's used, and our 6 nav tabs and 3 forms don't need all the overhead of React. So for people in a similar situation, this article really rings true.