What is RxJS and what are its top alternatives?
Top Alternatives to RxJS
Lots of people use React as the V in MVC. Since React makes no assumptions about the rest of your technology stack, it's easy to try it out on a small feature in an existing project. ...
It emphasizes a purer functional style. Immutability and side-effect free functions are at the heart of its design philosophy. This can help you get the job done with simple, elegant code. ...
MobX is a battle tested library that makes state management simple and scalable by transparently applying functional reactive programming (TFRP). React and MobX together are a powerful combination. React renders the application state by providing mechanisms to translate it into a tree of renderable components. MobX provides the mechanism to store and update the application state that React then uses. ...
An alternative side effect model for Redux apps
Akka is a toolkit and runtime for building highly concurrent, distributed, and resilient message-driven applications on the JVM. ...
Netty is a NIO client server framework which enables quick and easy development of network applications such as protocol servers and clients. It greatly simplifies and streamlines network programming such as TCP and UDP socket server. ...
Finagle is an extensible RPC system for the JVM, used to construct high-concurrency servers. Finagle implements uniform client and server APIs for several protocols, and is designed for high performance and concurrency. ...
RxJS alternatives & related posts
- Virtual dom651
- Data flow175
- Isn't an mvc framework124
- Reactive updates113
- Explicit app state111
- Learn once, write everywhere23
- Uni-directional data flow19
- Easy to Use16
- Works great with Flux Architecture14
- Great perfomance10
- Built by Facebook8
- TypeScript support5
- Easy to start4
- Feels like the 90s4
- Server side views3
- Fancy third party tools3
- Has arrow functions2
- Strong Community2
- Beautiful and Neat Component Management2
- Great migration pathway for older systems2
- Fast evolving2
- Simple, easy to reason about and makes you productive2
- Allows creating single page applications2
- Excellent Documentation2
- Rich ecosystem2
- Scales super well2
- Just the View of MVC2
- Super easy2
- Very gentle learning curve2
- Server Side Rendering2
- Has functional components2
- Start simple1
- Every decision architecture wise makes sense1
- Split your UI into components with one true state1
- Requires discipline to keep architecture organized35
- No predefined way to structure your app23
- Need to be familiar with lots of third party packages21
- Not enterprise friendly7
- One-way binding only4
- State consistency with backend neglected2
- Bad Documentation2
related React posts
I am starting to become a full-stack developer, by choosing and learning .NET Core for API Development, Angular CLI / React for UI Development, MongoDB for database, as it a NoSQL DB and Flutter / React Native for Mobile App Development. Using Postman, Markdown and Visual Studio Code for development.
I picked up an idea to develop and it was no brainer I had to go with React for the frontend. I was faced with challenges when it came to what component framework to use. I had worked extensively with Material-UI but I needed something different that would offer me wider range of well customized components (I became pretty slow at styling). I brought in Evergreen after several sampling and reads online but again, after several prototype development against Evergreen—since I was using TypeScript and I had to import custom Type, it felt exhaustive. After I validated Evergreen with the designs of the idea I was developing, I also noticed I might have to do a lot of styling. I later stumbled on Material Kit, the one specifically made for React . It was promising with beautifully crafted components, most of which fits into the designs pages I had on ground.
A major problem of Material Kit for me is it isn't written in TypeScript and there isn't any plans to support its TypeScript version. I rolled up my sleeve and started converting their components to TypeScript and if you'll ask me, I am still on it.
In summary, I used the Create React App with TypeScript support and I am spending some time converting Material Kit to TypeScript before I start developing against it. All of these components are going to be hosted on Bit.
If you feel I am crazy or I have gotten something wrong, I'll be willing to listen to your opinion. Also, if you want to have a share of whatever TypeScript version of Material Kit I end up coming up with, let me know.
- Automatically curried2
- Point free programming1
related Ramda posts
- It's just stupidly simple, yet so magical26
- Easier and cleaner than Redux18
- Automagic updates13
- React integration13
- Computed properties10
- ES6 observers and obversables8
- Global stores7
- Flexible architecture the requeriment3
- Has own router package (mobx-router)1
related MobX posts
The front end for Heap begun to grow unwieldy. The original jQuery pieces became difficult to maintain and scale, and a decision was made to introduce Backbone.js, Marionette, and TypeScript. Ultimately this ended up being a “detour” in the search for a scalable and maintainable front-end solution. The system did allow for developers to reuse components efficiently, but adding features was a difficult process, and it eventually became a bottleneck in advancing the product.
Today, the Heap product consists primarily of a customer-facing dashboard powered by React, MobX, and TypeScript on the front end. We wrote our migration to React and MobX in detail last year here.
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.
- Easy to test7
- Easy to learn1
related redux-saga posts
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.
related axios posts
- Great concurrency model31
- Actor Library11
- Open source10
- Message driven5
- Mixing futures with Akka tell is difficult3
- Closing of futures2
- No type safety2
- Typed actors still not stable1
- Very difficult to refactor0
related Akka posts
To solve the problem of scheduling and executing arbitrary tasks in its distributed infrastructure, PagerDuty created an open-source tool called Scheduler. Scheduler is written in Scala and uses Cassandra for task persistence. It also adds Apache Kafka to handle task queuing and partitioning, with Akka to structure the library’s concurrency.
The service’s logic schedules a task by passing it to the Scheduler’s Scala API, which serializes the task metadata and enqueues it into Kafka. Scheduler then consumes the tasks, and posts them to Cassandra to prevent data loss.
- High Performance7
- Easy to use3
- Just like it3
- Limited resources to learn from1