Redux vs Svelte: What are the differences?
"State is predictable" is the top reason why over 175 developers like Redux, while over 3 developers mention "All in one" as the leading cause for choosing Svelte.
Redux and Svelte are both open source tools. It seems that Redux with 49.5K GitHub stars and 12.8K forks on GitHub has more adoption than Svelte with 20.6K GitHub stars and 769 GitHub forks.
What is Redux?
What is Svelte?
Need advice about which tool to choose?Ask the StackShare community!
Sign up to add, upvote and see more prosMake informed product decisions
What are the cons of using Svelte?
Sign up to add, upvote and see more consMake informed product decisions
Sign up to get full access to all the companiesMake informed product decisions
What tools integrate with Svelte?
Sign up to get full access to all the tool integrationsMake informed product decisions
Working on a project recently, wanted an easy modern frontend to work with, decoupled from our backend. To get things going quickly, decided to go with React, Redux.js, redux-saga, Bootstrap.
On the backend side, Go is a personal favourite, and wanted to minimize server overheads so went with a #serverless architecture leveraging AWS Lambda, AWS CloudFormation, Amazon DynamoDB, etc.
For IDE/tooling I tend to stick to the #JetBrains tools: WebStorm / Goland.
Obviously using Git, with GitLab private repo's for managing code/issues/etc.
I'm building a new process management tool. I decided to build with Rails as my backend, using Sidekiq for background jobs. I chose to work with these tools because I've worked with them before and know that they're able to get the job done. They may not be the sexiest tools, but they work and are reliable, which is what I was optimizing for. For data stores, I opted for PostgreSQL and Redis. Because I'm planning on offering dashboards, I wanted a SQL database instead of something like MongoDB that might work early on, but be difficult to use as soon as I want to facilitate aggregate queries.
By switching our state management to MobX we removed approximately 40% of our boilerplate code and simplified our front-end development flow, which in the ends allowed us to focus more into product features rather than architectural choices.
Choosing redux-saga for my async Redux.js middleware, for a React application, instead of the typical redux-thunk .
Redux-saga is much easier to test than Redux-thunk - it requires no module mocking at all. Converting from redux-thunk to redux-saga is easy enough, as you are only refactoring the action creators - not your redux store or your react components. I've linked a github repo that shows the same solution with both, including Jest tests.
Frontend choice was basically pre-ordained to be React. Seems like a strong choice on merits alone, plus I needed to learn it to stay current. I never liked Redux.js from the first time I tried to work with it, but a mate had recommended MobX and after watching a few videos I felt like I could fit the mental model of hit in my head. Using Material-UI which is a great timesaver and make sure I throw a few bucks their way every month via the open source collective.
Defaulted to Rails with PostgreSQL just because that's where my past strength as a dev had been. First prototype was in Go but was struggling a bit with the quality of libraries I needed so I went back to old faithful.
As soon as TypeScript was supported by default in Create React App I ported everything over. That combined with swagger code gen has given me really good type safety from the API boundary and above. I semi-regret the Go/Rails decision because I miss the type safety despite pain points with libraries.
I will probably look to flip back to Go gradually (probably via lambda) at a point where it makes sense for the business.
After splitting our monolith into a Rails API + a React Redux.js frontend app, it became a necessity to monitor frontend errors. Our frontend application is not your typical website, and features a lot of interesting SPA mechanics that need to be followed closely (many async flows, redux-saga , etc.) in addition to regular browser incompatibility issues. Rollbar kicks in so that we can monitor every bug that happens on our frontend, and aggregate this with almost 0 work. The number of occurrences and affected browsers on each occurence helps us understand the priority and severity of bugs even when our users don't tell us about them, so we can decide whether we need to fix this bug that was encountered by 1k users in less than a few days days VERSUS telling this SINGLE user to switch browsers because he's using a very outdated version that no one else uses. Now we also use Rollbar with Rails, Sidekiq and even AWS Lambda errors since the interface is quite convenient.
Back at early 2017 the confusion and controversy around the future of AngularJS was at full swing. Also, the Angular 2 looked quite restrictive (or prescriptive even) when we did the assessment what to choose for Katana. React came out on top because it's community looked healthier, future more solid. And as you all know, one decision leads to many others: Redux, redux-saga , Axios
I use React because it is well engineered, has a huge community behind it, and allows for modular development (allowing you to handle state management yourself). I've been using React since before 1.0 (or whatever number it was they chose after 0.X). Having said this, I'm not saying other UI libraries are worse. I've barely used the other two big ones.
If using React with a non-trivial application, I heavily recommend using Redux for state management. There is no awful magic or convoluted workflow to Redux (you might not think so when starting on it, but once the light comes on, I hope you'll agree). It's all just loosely coupled state management. Remember to export your connected components separately so you can unit test the component without redux.
Though Redux makes encoding some interactions unnatural, the ease of debugging makes it worthwhile. Additionally, Redux makes it easy to implement saving/bookmarking/sharing just by serializing state
Redux's middleware is great for separating concerns, e.g., requests, errors, telemetry, etc.
Our reducers use immutability-helper to update state
We love functional approach to writing apps and Redux is thus the premium choice in this matter. The inner beauty of the state tree is unbeatable. We recently learned to solve common tasks via middleware. And the Redux Chrome extension is such a marvel - our developers request extra monitors just to have it nearby.
Our state management library of choice. Redux has a simple concept, but it's flexible enough and it's React binding library, react-redux, contains a lot of performance-optimized code to make the most out of this combo.
I have been using React/Flux since just about the beginning of React time. Redux is a great upgrade and extension of the core flux concepts, and brings immutable and strict declarative state to the apps I build.
- Ideal for microfrontends
- Natural component model
- Easy to learn
- Fast and extremely small
- Compiles both webcomponents and plain components Great community